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

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

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. スモールビジネスに携わる方が より創造的な活動にフォーカスできるように