Tweet
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

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