performance-tuning-of-the-microservice.pdf

Transcript

1. マイクロサービスの
 性能改善
 〜コロナ時代の医療業界を支援するエムスリーのプロダクト開発の舞台裏〜
 （2020/07/09） 

2. 自己紹介
 
 高島 亮祐（@rst76）
 エムスリー 株式会社（2019/01-）
 基盤チームで認証サービスや様々なレガシーサービスの改善を担当
 好きなもの：宣言的言語（Haskell、SQL）

3. なぜ性能改善が必要になったか
 • エムスリーの Web サイトは医療従事者に限定
 →アクセス数が予想しやすい
 • COVID-19 でサイト全体のアクセス数が増えた
 ◦ COVID-19 に関する情報提供 
 ◦ 医療機関へのマスク配布などのキャンペーン 
 • さらに Web 講演会というリアルタイムの動画配信も増えた
 ◦ 講演会開始時にアクセスが集中する 
 • アクセスが急増して色々なところが限界に・・・

4. ケース１：サーキットブレーカー
 • 認証サービス A からレコメンデーションサービス B を呼んでいる
 • サービス B で時間がかかっている
 • サービス B は複雑で短期の改善は難しい
 • UX・利益に直結するサービスなので、できるだけ呼び出しを減らしたくない
 
 
 
 →負荷が上がったときだけ呼び出しを止めるサーキットブレーカーを導入
 サービス A
 サービス B

5. ケース１：サーキットブレーカー
 実装のポイント
 • 応答時間を切替の基準にするとバラつきやすい
 →アクセス数を基準に
 • 止めたい時間は数分だが秒単位に集計すると切替が頻繁に発生
 →数十秒〜分単位で集計して切替
 

6. ケース１：サーキットブレーカー
 サービス A の呼出回数 
 サービス B の呼出回数 
 サービス A の応答時間 
 • 必要な期間だけサービス B の呼び出しを止めて、応答時間を改善することができた 
 • そもそもサービス B の応答時間を改善して、サーキットブレーカーを廃止したい 

7. ケース２：誰が遅いのか
 • 認証サービス A から呼んでいるサービス C が遅い
 • セキュリティ関連のサービスなのでスキップするわけにはいかない
 • サービス C の遅延ログにもとづいて AP を改善
 • 遅延ログは減ったが、相変わらず遅い！？
 • AP よりも手前の Web サーバーで時間がかかっていた
 
 サービス C のクラウド移行が完了しました！ 同僚 0 さん
 エムスリーではオンプレミスのサービスのクラウド移行を進めている
 ちょうどサービス C がクラウドに移行したので、呼び出し先を切替

8. オンプレミス
 クラウド
 その他
 サービス
 その他
 サービス
 ケース２：誰が遅いのか
 サービス A
 Web
 サーバー
 サービス C
 サービス C
 その他
 サービス
 中から見た性能と
 外から見た性能は
 必ずしも一致しない
 移行前の経路
 
 移行後の経路

9. ケース３：タイムアウト
 • サービス A の呼び出し元から、タイムアウトになるとの連絡が・・・
 • そんなはずはない！いろいろ改善して性能は十分なはず！
 • 呼び出し元のログをよくよく確認すると
 Timeout waiting for connection from pool
 （コネクションプールからの HTTP コネクション取得のタイムアウト）
 • アクセス数の増加により同時接続数も増え、接続が足りなくなっていた
 →呼び出し元の最大接続数を増やして対応
 Read Timeout、Connect Timeout など、様々なタイムアウトがあるので注意

10. ケース４：誰が遅いのか（再）
 • サービス A の別の呼び出し元からタイムアウトの通知
 • サービス A の応答時間は変わらず問題なし
 • クライアント（呼び出し元）の接続設定を変更するも効果なし
 ロードバランサーの SSL 接続上限に達していた
 これサーバーとクライアントの間に LB いますよね ！！！ 同僚 H さん
 何が遅いのかぜんぜん分からなくて・・・
11. サービス A の AP サーバーのみクラウド移行する予定だったが、
 急遽 Web サーバーも含めて移行し、ロードバランサーを回避
 オンプレミス
 クラウド
 ケース４：誰が遅いのか（再）
 その他の
 サービス
 ロード
 バランサー
 サービス A
 Web
 サービス A
 Web
 移行前の経路
 
 移行後の経路
 サービス A
 AP
 サービス A
 AP
 方針はシンプルだが Web サーバーには過去の設定が堆積しており・・・ 
 50+

12. ケース４：誰が遅いのか（再）
 • サービス A の性能問題は解決！！！
 • 残されたロードバランサーも、サービス A や他のサービスがロードバランサーを回 避したことで、接続上限に張り付くことはなくなった
 • めでたしめでたし
 対応前
 対応後

13. 性能の改善は性能の把握から
 • 外から見た性能
 ◦ Web サーバーや AP サーバーの境界それぞれで測定が必要 
 ◦ アクセスログを Elasticsearch & Kibana で 
 ▪ In: リクエスト数・Out: 応答時間（パーセンタイル値） 
 ▪ 機能ごと／クライアントごと 
 • 中から見た性能
 ◦ ログ（StopWatch などのタイマーライブラリを利用） 
 • 今回話さなかったもの
 ◦ 分散トレーシング

14. まとめ
 • 一般的な Web システムの性能問題
 DB：AP：NW = 7 : 2 : 1 （個人的な経験則）
 エムスリーのサービスの粒度は細かい
 →サービスを細分化すると NW の問題がメインに
 
 • 適切に性能を改善するには、正しい現状把握がだいじ