Upgrade to Pro — share decks privately, control downloads, hide ads and more …

freeeのクラウドサービス活用術とパフォーマンス改善活動のご紹介

foostan
June 19, 2017

 freeeのクラウドサービス活用術とパフォーマンス改善活動のご紹介

freeeでは会計freeeや給与計算freeeなどのクラウドサービスを開発・運営していますが、実際にはAWSやNew Relicといった様々なクラウドサービスを活用しています。freeeでのクラウドサービス活用術として、いくつか事例を交えながら紹介したいと思います。またサーバのレスポンスタイムの改善にフォーカスして、どのように行っているかをより具体的に、技術的な観点と組織的な観点でご紹介いたします。

foostan

June 19, 2017
Tweet

More Decks by foostan

Other Decks in Technology

Transcript

  1. freee株式会社 開発本部 足立紘亮
    2017/06/19
    freeeのクラウドサービス活用術とパフォーマン
    ス改善活動のご紹介

    View full-size slide

  2. アジェンダ
    - freeeにおけるクラウドサービス利用の考え方
    - クラウドサービスの利用例
    - インフラ構築/運用における利用例
    - アプリケーション開発/運用における利用例
    - クラウドサービスを活用したパフォーマンス改善活動

    View full-size slide

  3. 自己紹介
    足立 紘亮 ( foostan )
    ソフトウェアエンジニア
    サーバーサイド(Rails)からフロントエンド
    (ES6+React)に至るまでWebアプリケーション開発
    を幅広くやっている。
    開発環境の整備やパフォーマンス改善などにも興
    味があり、それらも積極的に行っている。

    View full-size slide

  4. freeeの紹介

    View full-size slide

  5. freeeの紹介

    View full-size slide

  6. freeeの紹介
    スモールビジネスの各成長段階をサポートするサービスの提供

    View full-size slide

  7. freee におけるクラウドサービス利用の考え方

    View full-size slide

  8. 社内ではクラウドサービスを活用することを推
    進している
    業務を効率化するために積極的に利用する
    アレもこれもクラウドにデータあげちゃって大丈夫?
    これ情報漏れたりしない?
    セキュリティの担保は CSIRT で行う

    View full-size slide

  9. セキュリティの担保はCSIRTで行う
    - セキュリティ担当者の教育・啓発
    - セキュリティ事故を予防・検知する仕組みづくり
    - セキュリティ事故の緊急対応
    - 社外向けのセキュリティ窓口(他社CSIRTとの情報交換も)
    サービスの性質(扱うデータなど)を
    理解した上で利用する

    View full-size slide

  10. freeeで使っているサービス(一部)

    View full-size slide

  11. インフラ構築/運用における
    クラウドサービスの利用例

    View full-size slide

  12. AWS活用例
    基本的には普通の構成
    - ELB(ALB),EC2,RDS,ElastiCache,CloudFront,...
    - マイクロサービス化しているので、複数のセットが存在し
    ている
    serverlessアーキテクチャも一部採用
    - 例
    - メール取り込み機能(SES + Lambda + DynamoDB)
    - Livechatのwebhook(APIGateway + Lambda)

    View full-size slide

  13. 自動化
    autoscalingを前提とした構成なので構築自動化は必須
    - 台数調整によるコスト適正化
    - 時間による台数調整
    - 非同期キューや負荷に応じた調整
    - auto healing
    - インスタンスの調子が悪くなれば勝手に作り直す
    - security patch適用等によるインスタンス入れ替え
    - apt-get dist-upgradeしたAMIを作って入れ替える

    View full-size slide

  14. 監視
    - NewRelic
    - アプリケーション内部、DBのslow query
    - Mackerel
    - EC2のリソース監視や外形監視
    - alert通知
    - CloudWatch
    - autoscalingのトリガーとして利用
    - mackerelとintegrationが可能
    - Deep Security as a Service for AWS
    - セキュリティ監視

    View full-size slide

  15. アプリケーション開発/運用における
    クラウドサービスの利用例

    View full-size slide

  16. - Ruby on Rails のアプリケーション監視用にAPMを利用
    (Light 版と PRO 版を併用)
    - 外形監視として Browser を利用 (Light 版)
    - アラートはSlackに通知
    ※ 具体的な利用例は後述
    慢性的なパフォーマンス低下の把握
    突発的なパフォーマンス低下の検知

    View full-size slide

  17. バグの検知/管理
    エラー
    起票
    通知
    U C
    S
    ユーザとのコミュニケーション
    formから起票

    View full-size slide

  18. エラー
    起票
    通知
    U C
    S
    ユーザとのコミュニケーション
    formから起票
    https://www.bugsnag.com/product/ より転載
    - エラーをサマライズ表示
    - 期間や属性で検索

    View full-size slide

  19. エラー
    起票
    通知
    U C
    S
    ユーザとのコミュニケーション
    formから起票
    https://www.bugsnag.com/product/ より転載
    - スタックトレース表示
    - カスタム属性の付与(ユーザの特定)

    View full-size slide

  20. エラー
    起票
    通知
    U C
    S
    ユーザとのコミュニケーション
    formから起票
    https://ja.atlassian.com/agile/kanban より転載
    - チケット管理
    - CSとEnz間でのコミュニケーション

    View full-size slide

  21. デプロイ Step1
    E
    HUBOT(ECS) with
    ElastiCache
    Jenkins(EC2)
    S3
    ①「デプロイしたい」
    ② PR作成
    & マージ
    ※ 公開用に簡略化しています
    Web servers (EC2)

    View full-size slide

  22. デプロイ Step2
    E
    HUBOT(ECS) with
    ElastiCache
    Jenkins(EC2)
    S3
    Web servers (EC2)
    ①「デプロイするぞ」
    ② デプロイ
    Job実行
    ④ ビルド & 成果物
    を保存
    ⑥ 成果物取
    得 & 展開
    ③ リリースブランチ
    をフェッチ
    ⑤ デプロイ実行
    ※ 公開用に簡略化しています

    View full-size slide

  23. クラウドサービスを活用した
    パフォーマンス改善活動

    View full-size slide

  24. http://qiita.com/foostan/items/5f5e2be16b009848b76b
    パフォーマンス改善活動

    View full-size slide

  25. チームを作った経緯
    ~ 遅いものはなんでも速くしたい ~
    1日3デプロイ
    新機能がバンバンリリースされる
    パフォーマンスが犠牲にされているケースが垣間見れた

    View full-size slide

  26. チームを作った経緯
    ~ 遅いものはなんでも速くしたい ~
    問題意識はあった
    直したいけど手を付けられていない
    チーム作ってみんなで改善していこう!

    View full-size slide

  27. 何をしているか
    - パフォーマンスの確認
    - NewRelic + Re:dash などを利用
    - 改善ポイントの共有/実施
    - 定期的なミーティング
    - 進捗確認
    - 作戦会議
    - 全社向けに活動報告

    View full-size slide

  28. NewRelic APMで改善ポイントを探る

    View full-size slide

  29. 全体の概要を確認する
    何を見るか?

    View full-size slide

  30. 全体の概要を確認する
    表示期間の指定

    View full-size slide

  31. 全体の概要を確認する
    トランザクション時間の変動とその内訳

    View full-size slide

  32. 全体の概要を確認する
    安定性を示す数値の変動

    View full-size slide

  33. 全体の概要を確認する
    主なトランザクションの内訳

    View full-size slide

  34. 慢性的にパフォーマンスが悪い
    → トランザクションから原因を探る場合
    トランザクションの詳細確認

    View full-size slide

  35. 慢性的にパフォーマンスが悪い
    → トランザクションから原因を探る場合
    指定期間内でかかった時間が長い順でソート

    View full-size slide

  36. 慢性的にパフォーマンスが悪い
    → トランザクションから原因を探る場合
    順位と割合

    View full-size slide

  37. 慢性的にパフォーマンスが悪い
    → トランザクションから原因を探る場合

    View full-size slide

  38. 慢性的にパフォーマンスが悪い
    → トランザクションから原因を探る場合
    内訳の確認

    View full-size slide

  39. 慢性的にパフォーマンスが悪い
    → トランザクションから原因を探る場合
    より詳細な内訳

    View full-size slide

  40. 慢性的にパフォーマンスが悪い
    → トランザクションから原因を探る場合
    認証基盤へのアクセスの割合が大きい

    View full-size slide

  41. 慢性的にパフォーマンスが悪い
    → トランザクションから原因を探る場合
    見るべき箇所(コード)がはっきりする

    View full-size slide

  42. 慢性的にパフォーマンスが悪い
    → Databaseから原因を探る場合
    DBの詳細確認

    View full-size slide

  43. 慢性的にパフォーマンスが悪い
    → Databaseから原因を探る場合
    指定期間内でかかった時間が長い順でソート

    View full-size slide

  44. 慢性的にパフォーマンスが悪い
    → Databaseから原因を探る場合
    順位と割合

    View full-size slide

  45. 慢性的にパフォーマンスが悪い
    → Databaseから原因を探る場合
    とあるコントローラで半分ぐらい締めている

    View full-size slide

  46. 慢性的にパフォーマンスが悪い
    → Databaseから原因を探る場合
    見るべき箇所(コード)がはっきりする

    View full-size slide

  47. 突発的なパフォーマンス低下
    → アラートから原因を探る場合
    アラート設定をしておけばSlackに通知が来る

    View full-size slide

  48. 突発的なパフォーマンス低下
    → アラートから原因を探る場合
    グラフ上にピンクの線が表示されるので期間を絞りこみつ
    つ原因を探る

    View full-size slide

  49. NewRelic Browser で改善ポイントを探る

    View full-size slide

  50. 全体の概要を確認する
    ロード時間の内訳

    View full-size slide

  51. 全体の概要を確認する
    https://docs.newrelic.com/docs/browser/new-relic-browser/page-load-timing-resources/page-load-timing-process

    View full-size slide

  52. Page Views で遅いページを把握する
    指定期間内でかかった時間が長い順でソート

    View full-size slide

  53. 突発的なパフォーマンス低下
    → アラートから原因を探る場合
    アラートが発生した箇所にピンクの線が表示される

    View full-size slide

  54. 突発的なパフォーマンス低下
    → アラートから原因を探る場合
    内訳を見てみるとフロント側(DOM processing, Page
    rendering)で問題が起こっていることがわかる)

    View full-size slide

  55. 突発的なパフォーマンス低下
    → アラートから原因を探る場合
    - フロント側に問題がある場合、実際にアクセスしても居る
    のが手っ取り早い
    - サードパーティ製のサービスを利用している場合、そちら
    に障害があってもアラートが鳴る
    - この場合、Chrome Developer Tools の Network などで
    おかしな通信が発生していないか確認する(経験上だい
    たいがこのケース)

    View full-size slide

  56. NewRelic の API を利用して独自のViewを作る

    View full-size slide

  57. New Relic のおしいところ
    - ログの保持期間が短い(Browserの場合はPRO版でも90
    日)
    - 独自のViewを作るにはPRO版にする必要がある(費用
    的に全台をPRO版にはできないので取れるデータ量に
    制限がある)

    View full-size slide

  58. New Relic の API を利用する
    - New Relic の API は WebUI で見れる大抵の情報を取得す
    ることができる
    - Web上で試せるので得たい情報の取得方法がすぐわかる

    View full-size slide

  59. API で得た情報をRe:dashで可視化する
    - Re:dash : BIダッシュボード
    - ホスティング版とOSS版がある
    - データソースに AWS Redshift を利用できる

    View full-size slide

  60. API で得た情報をRe:dashで可視化する
    Agentで収集
    fluentd で パフォーマンスロ
    グを収集
    APIで取得
    バッチ同期
    可視化
    S3

    View full-size slide

  61. API で得た情報をRe:dashで可視化する
    長期間のサマリ表示
    主要ページの Page Rendering 表示
    悪化ポイントと改善ポイントがはっきりする

    View full-size slide

  62. API で得た情報をRe:dashで可視化する
    主要ページの Network 表示
    ログインページだけ極端におそい(ブラウザキャッシュが効いてな
    い状態のアクセスが多いため)

    View full-size slide

  63. アプリケーションからパフォーマンスログを取得して
    可視化する

    View full-size slide

  64. パフォーマンスログを可視化する
    Agentで収集
    fluentd で パフォーマンスロ
    グを収集
    APIで取得
    バッチ同期
    可視化
    S3

    View full-size slide

  65. パフォーマンスログ
    - Controller/Action の実行に掛かった時間
    - ユーザID
    - 事業所ID
    などの情報を含む時系列データ

    View full-size slide

  66. パフォーマンスログの特徴
    - パフォーマンスはデータ量に依存するため、事業所に
    よって異なる
    - 個人の事業所の場合はあまり問題にならない
    - 法人の場合はデータ量が桁違いになるため影響が出てく

    事業所の特徴毎にパフォーマンスを監視する必要がある

    View full-size slide

  67. パフォーマンスログを可視化する
    - とあるAPIのパフォーマンスの遷移
    - 2017-18 までに改善されたがそこを堺に悪化している
    - V字になっているグラフは要注意で定期的に確認して改善
    をしている

    View full-size slide

  68. パフォーマンスログを可視化する
    - 改善してからパフォーマンスを維持しているAPI
    - このようなグラフを共有すると改善に対するモチベーション
    が上がる

    View full-size slide

  69. パフォーマンスログを可視化する
    - 同じAPIにおける事業所の特徴による違い
    - 青線は全体平均、赤線は取引数の多い事業所
    - この変化は平均だけ見ていると気付けない

    View full-size slide

  70. スモールビジネスに携わる方が
    より創造的な活動にフォーカスできるように

    View full-size slide