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

D84f970274539b7370446857459bdd8c?s=47 foostan
June 19, 2017

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

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

D84f970274539b7370446857459bdd8c?s=128

foostan

June 19, 2017
Tweet

Transcript

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

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

    クラウドサービスを活用したパフォーマンス改善活動
  3. 自己紹介 足立 紘亮 ( foostan ) ソフトウェアエンジニア サーバーサイド(Rails)からフロントエンド (ES6+React)に至るまでWebアプリケーション開発 を幅広くやっている。

    開発環境の整備やパフォーマンス改善などにも興 味があり、それらも積極的に行っている。
  4. freeeの紹介

  5. freeeの紹介

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

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

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

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

    理解した上で利用する
  10. freeeで使っているサービス(一部)

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

  12. AWS活用例 基本的には普通の構成 - ELB(ALB),EC2,RDS,ElastiCache,CloudFront,... - マイクロサービス化しているので、複数のセットが存在し ている serverlessアーキテクチャも一部採用 - 例

    - メール取り込み機能(SES + Lambda + DynamoDB) - Livechatのwebhook(APIGateway + Lambda)
  13. 自動化 autoscalingを前提とした構成なので構築自動化は必須 - 台数調整によるコスト適正化 - 時間による台数調整 - 非同期キューや負荷に応じた調整 - auto

    healing - インスタンスの調子が悪くなれば勝手に作り直す - security patch適用等によるインスタンス入れ替え - apt-get dist-upgradeしたAMIを作って入れ替える
  14. 監視 - NewRelic - アプリケーション内部、DBのslow query - Mackerel - EC2のリソース監視や外形監視

    - alert通知 - CloudWatch - autoscalingのトリガーとして利用 - mackerelとintegrationが可能 - Deep Security as a Service for AWS - セキュリティ監視
  15. アプリケーション開発/運用における クラウドサービスの利用例

  16. - Ruby on Rails のアプリケーション監視用にAPMを利用 (Light 版と PRO 版を併用) -

    外形監視として Browser を利用 (Light 版) - アラートはSlackに通知 ※ 具体的な利用例は後述 慢性的なパフォーマンス低下の把握 突発的なパフォーマンス低下の検知
  17. バグの検知/管理 エラー 起票 通知 U C S ユーザとのコミュニケーション formから起票

  18. エラー 起票 通知 U C S ユーザとのコミュニケーション formから起票 https://www.bugsnag.com/product/ より転載

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

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

    - チケット管理 - CSとEnz間でのコミュニケーション
  21. デプロイ Step1 E HUBOT(ECS) with ElastiCache Jenkins(EC2) S3 ①「デプロイしたい」 ②

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

    (EC2) ①「デプロイするぞ」 ② デプロイ Job実行 ④ ビルド & 成果物 を保存 ⑥ 成果物取 得 & 展開 ③ リリースブランチ をフェッチ ⑤ デプロイ実行 ※ 公開用に簡略化しています
  23. クラウドサービスを活用した パフォーマンス改善活動

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

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

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

  27. 何をしているか - パフォーマンスの確認 - NewRelic + Re:dash などを利用 - 改善ポイントの共有/実施

    - 定期的なミーティング - 進捗確認 - 作戦会議 - 全社向けに活動報告
  28. NewRelic APMで改善ポイントを探る

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  55. 突発的なパフォーマンス低下 → アラートから原因を探る場合 - フロント側に問題がある場合、実際にアクセスしても居る のが手っ取り早い - サードパーティ製のサービスを利用している場合、そちら に障害があってもアラートが鳴る -

    この場合、Chrome Developer Tools の Network などで おかしな通信が発生していないか確認する(経験上だい たいがこのケース)
  56. NewRelic の API を利用して独自のViewを作る

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

  58. New Relic の API を利用する - New Relic の API

    は WebUI で見れる大抵の情報を取得す ることができる - Web上で試せるので得たい情報の取得方法がすぐわかる
  59. API で得た情報をRe:dashで可視化する - Re:dash : BIダッシュボード - ホスティング版とOSS版がある - データソースに

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

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

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

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

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

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

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

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

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

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

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