Link
Embed
Share
Beginning
This slide
Copy link URL
Copy link URL
Copy iframe embed code
Copy iframe embed code
Copy javascript embed code
Copy javascript embed code
Share
Tweet
Share
Tweet
Slide 1
Slide 1 text
freee株式会社 開発本部 足立紘亮 2017/06/19 freeeのクラウドサービス活用術とパフォーマン ス改善活動のご紹介
Slide 2
Slide 2 text
アジェンダ - freeeにおけるクラウドサービス利用の考え方 - クラウドサービスの利用例 - インフラ構築/運用における利用例 - アプリケーション開発/運用における利用例 - クラウドサービスを活用したパフォーマンス改善活動
Slide 3
Slide 3 text
自己紹介 足立 紘亮 ( foostan ) ソフトウェアエンジニア サーバーサイド(Rails)からフロントエンド (ES6+React)に至るまでWebアプリケーション開発 を幅広くやっている。 開発環境の整備やパフォーマンス改善などにも興 味があり、それらも積極的に行っている。
Slide 4
Slide 4 text
freeeの紹介
Slide 5
Slide 5 text
freeeの紹介
Slide 6
Slide 6 text
freeeの紹介 スモールビジネスの各成長段階をサポートするサービスの提供
Slide 7
Slide 7 text
freee におけるクラウドサービス利用の考え方
Slide 8
Slide 8 text
社内ではクラウドサービスを活用することを推 進している 業務を効率化するために積極的に利用する アレもこれもクラウドにデータあげちゃって大丈夫? これ情報漏れたりしない? セキュリティの担保は CSIRT で行う
Slide 9
Slide 9 text
セキュリティの担保はCSIRTで行う - セキュリティ担当者の教育・啓発 - セキュリティ事故を予防・検知する仕組みづくり - セキュリティ事故の緊急対応 - 社外向けのセキュリティ窓口(他社CSIRTとの情報交換も) サービスの性質(扱うデータなど)を 理解した上で利用する
Slide 10
Slide 10 text
freeeで使っているサービス(一部)
Slide 11
Slide 11 text
インフラ構築/運用における クラウドサービスの利用例
Slide 12
Slide 12 text
AWS活用例 基本的には普通の構成 - ELB(ALB),EC2,RDS,ElastiCache,CloudFront,... - マイクロサービス化しているので、複数のセットが存在し ている serverlessアーキテクチャも一部採用 - 例 - メール取り込み機能(SES + Lambda + DynamoDB) - Livechatのwebhook(APIGateway + Lambda)
Slide 13
Slide 13 text
自動化 autoscalingを前提とした構成なので構築自動化は必須 - 台数調整によるコスト適正化 - 時間による台数調整 - 非同期キューや負荷に応じた調整 - auto healing - インスタンスの調子が悪くなれば勝手に作り直す - security patch適用等によるインスタンス入れ替え - apt-get dist-upgradeしたAMIを作って入れ替える
Slide 14
Slide 14 text
監視 - NewRelic - アプリケーション内部、DBのslow query - Mackerel - EC2のリソース監視や外形監視 - alert通知 - CloudWatch - autoscalingのトリガーとして利用 - mackerelとintegrationが可能 - Deep Security as a Service for AWS - セキュリティ監視
Slide 15
Slide 15 text
アプリケーション開発/運用における クラウドサービスの利用例
Slide 16
Slide 16 text
- Ruby on Rails のアプリケーション監視用にAPMを利用 (Light 版と PRO 版を併用) - 外形監視として Browser を利用 (Light 版) - アラートはSlackに通知 ※ 具体的な利用例は後述 慢性的なパフォーマンス低下の把握 突発的なパフォーマンス低下の検知
Slide 17
Slide 17 text
バグの検知/管理 エラー 起票 通知 U C S ユーザとのコミュニケーション formから起票
Slide 18
Slide 18 text
エラー 起票 通知 U C S ユーザとのコミュニケーション formから起票 https://www.bugsnag.com/product/ より転載 - エラーをサマライズ表示 - 期間や属性で検索
Slide 19
Slide 19 text
エラー 起票 通知 U C S ユーザとのコミュニケーション formから起票 https://www.bugsnag.com/product/ より転載 - スタックトレース表示 - カスタム属性の付与(ユーザの特定)
Slide 20
Slide 20 text
エラー 起票 通知 U C S ユーザとのコミュニケーション formから起票 https://ja.atlassian.com/agile/kanban より転載 - チケット管理 - CSとEnz間でのコミュニケーション
Slide 21
Slide 21 text
デプロイ Step1 E HUBOT(ECS) with ElastiCache Jenkins(EC2) S3 ①「デプロイしたい」 ② PR作成 & マージ ※ 公開用に簡略化しています Web servers (EC2)
Slide 22
Slide 22 text
デプロイ Step2 E HUBOT(ECS) with ElastiCache Jenkins(EC2) S3 Web servers (EC2) ①「デプロイするぞ」 ② デプロイ Job実行 ④ ビルド & 成果物 を保存 ⑥ 成果物取 得 & 展開 ③ リリースブランチ をフェッチ ⑤ デプロイ実行 ※ 公開用に簡略化しています
Slide 23
Slide 23 text
クラウドサービスを活用した パフォーマンス改善活動
Slide 24
Slide 24 text
http://qiita.com/foostan/items/5f5e2be16b009848b76b パフォーマンス改善活動
Slide 25
Slide 25 text
チームを作った経緯 ~ 遅いものはなんでも速くしたい ~ 1日3デプロイ 新機能がバンバンリリースされる パフォーマンスが犠牲にされているケースが垣間見れた
Slide 26
Slide 26 text
チームを作った経緯 ~ 遅いものはなんでも速くしたい ~ 問題意識はあった 直したいけど手を付けられていない チーム作ってみんなで改善していこう!
Slide 27
Slide 27 text
何をしているか - パフォーマンスの確認 - NewRelic + Re:dash などを利用 - 改善ポイントの共有/実施 - 定期的なミーティング - 進捗確認 - 作戦会議 - 全社向けに活動報告
Slide 28
Slide 28 text
NewRelic APMで改善ポイントを探る
Slide 29
Slide 29 text
全体の概要を確認する 何を見るか?
Slide 30
Slide 30 text
全体の概要を確認する 表示期間の指定
Slide 31
Slide 31 text
全体の概要を確認する トランザクション時間の変動とその内訳
Slide 32
Slide 32 text
全体の概要を確認する 安定性を示す数値の変動
Slide 33
Slide 33 text
全体の概要を確認する 主なトランザクションの内訳
Slide 34
Slide 34 text
慢性的にパフォーマンスが悪い → トランザクションから原因を探る場合 トランザクションの詳細確認
Slide 35
Slide 35 text
慢性的にパフォーマンスが悪い → トランザクションから原因を探る場合 指定期間内でかかった時間が長い順でソート
Slide 36
Slide 36 text
慢性的にパフォーマンスが悪い → トランザクションから原因を探る場合 順位と割合
Slide 37
Slide 37 text
慢性的にパフォーマンスが悪い → トランザクションから原因を探る場合
Slide 38
Slide 38 text
慢性的にパフォーマンスが悪い → トランザクションから原因を探る場合 内訳の確認
Slide 39
Slide 39 text
慢性的にパフォーマンスが悪い → トランザクションから原因を探る場合 より詳細な内訳
Slide 40
Slide 40 text
慢性的にパフォーマンスが悪い → トランザクションから原因を探る場合 認証基盤へのアクセスの割合が大きい
Slide 41
Slide 41 text
慢性的にパフォーマンスが悪い → トランザクションから原因を探る場合 見るべき箇所(コード)がはっきりする
Slide 42
Slide 42 text
慢性的にパフォーマンスが悪い → Databaseから原因を探る場合 DBの詳細確認
Slide 43
Slide 43 text
慢性的にパフォーマンスが悪い → Databaseから原因を探る場合 指定期間内でかかった時間が長い順でソート
Slide 44
Slide 44 text
慢性的にパフォーマンスが悪い → Databaseから原因を探る場合 順位と割合
Slide 45
Slide 45 text
慢性的にパフォーマンスが悪い → Databaseから原因を探る場合 とあるコントローラで半分ぐらい締めている
Slide 46
Slide 46 text
慢性的にパフォーマンスが悪い → Databaseから原因を探る場合 見るべき箇所(コード)がはっきりする
Slide 47
Slide 47 text
突発的なパフォーマンス低下 → アラートから原因を探る場合 アラート設定をしておけばSlackに通知が来る
Slide 48
Slide 48 text
突発的なパフォーマンス低下 → アラートから原因を探る場合 グラフ上にピンクの線が表示されるので期間を絞りこみつ つ原因を探る
Slide 49
Slide 49 text
NewRelic Browser で改善ポイントを探る
Slide 50
Slide 50 text
全体の概要を確認する ロード時間の内訳
Slide 51
Slide 51 text
全体の概要を確認する https://docs.newrelic.com/docs/browser/new-relic-browser/page-load-timing-resources/page-load-timing-process
Slide 52
Slide 52 text
Page Views で遅いページを把握する 指定期間内でかかった時間が長い順でソート
Slide 53
Slide 53 text
突発的なパフォーマンス低下 → アラートから原因を探る場合 アラートが発生した箇所にピンクの線が表示される
Slide 54
Slide 54 text
突発的なパフォーマンス低下 → アラートから原因を探る場合 内訳を見てみるとフロント側(DOM processing, Page rendering)で問題が起こっていることがわかる)
Slide 55
Slide 55 text
突発的なパフォーマンス低下 → アラートから原因を探る場合 - フロント側に問題がある場合、実際にアクセスしても居る のが手っ取り早い - サードパーティ製のサービスを利用している場合、そちら に障害があってもアラートが鳴る - この場合、Chrome Developer Tools の Network などで おかしな通信が発生していないか確認する(経験上だい たいがこのケース)
Slide 56
Slide 56 text
NewRelic の API を利用して独自のViewを作る
Slide 57
Slide 57 text
New Relic のおしいところ - ログの保持期間が短い(Browserの場合はPRO版でも90 日) - 独自のViewを作るにはPRO版にする必要がある(費用 的に全台をPRO版にはできないので取れるデータ量に 制限がある)
Slide 58
Slide 58 text
New Relic の API を利用する - New Relic の API は WebUI で見れる大抵の情報を取得す ることができる - Web上で試せるので得たい情報の取得方法がすぐわかる
Slide 59
Slide 59 text
API で得た情報をRe:dashで可視化する - Re:dash : BIダッシュボード - ホスティング版とOSS版がある - データソースに AWS Redshift を利用できる
Slide 60
Slide 60 text
API で得た情報をRe:dashで可視化する Agentで収集 fluentd で パフォーマンスロ グを収集 APIで取得 バッチ同期 可視化 S3
Slide 61
Slide 61 text
API で得た情報をRe:dashで可視化する 長期間のサマリ表示 主要ページの Page Rendering 表示 悪化ポイントと改善ポイントがはっきりする
Slide 62
Slide 62 text
API で得た情報をRe:dashで可視化する 主要ページの Network 表示 ログインページだけ極端におそい(ブラウザキャッシュが効いてな い状態のアクセスが多いため)
Slide 63
Slide 63 text
アプリケーションからパフォーマンスログを取得して 可視化する
Slide 64
Slide 64 text
パフォーマンスログを可視化する Agentで収集 fluentd で パフォーマンスロ グを収集 APIで取得 バッチ同期 可視化 S3
Slide 65
Slide 65 text
パフォーマンスログ - Controller/Action の実行に掛かった時間 - ユーザID - 事業所ID などの情報を含む時系列データ
Slide 66
Slide 66 text
パフォーマンスログの特徴 - パフォーマンスはデータ量に依存するため、事業所に よって異なる - 個人の事業所の場合はあまり問題にならない - 法人の場合はデータ量が桁違いになるため影響が出てく る 事業所の特徴毎にパフォーマンスを監視する必要がある
Slide 67
Slide 67 text
パフォーマンスログを可視化する - とあるAPIのパフォーマンスの遷移 - 2017-18 までに改善されたがそこを堺に悪化している - V字になっているグラフは要注意で定期的に確認して改善 をしている
Slide 68
Slide 68 text
パフォーマンスログを可視化する - 改善してからパフォーマンスを維持しているAPI - このようなグラフを共有すると改善に対するモチベーション が上がる
Slide 69
Slide 69 text
パフォーマンスログを可視化する - 同じAPIにおける事業所の特徴による違い - 青線は全体平均、赤線は取引数の多い事業所 - この変化は平均だけ見ていると気付けない
Slide 70
Slide 70 text
スモールビジネスに携わる方が より創造的な活動にフォーカスできるように