performance-tuning-of-the-microservice.pdf

B936321bf044487eaf990b605a8826d3?s=47 Ryosuke TAKASHIMA
July 09, 2020
620

 performance-tuning-of-the-microservice.pdf

B936321bf044487eaf990b605a8826d3?s=128

Ryosuke TAKASHIMA

July 09, 2020
Tweet

Transcript

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


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


  3. なぜ性能改善が必要になったか
 • エムスリーの Web サイトは医療従事者に限定
 →アクセス数が予想しやすい
 • COVID-19 でサイト全体のアクセス数が増えた
 ◦

    COVID-19 に関する情報提供 
 ◦ 医療機関へのマスク配布などのキャンペーン 
 • さらに Web 講演会というリアルタイムの動画配信も増えた
 ◦ 講演会開始時にアクセスが集中する 
 • アクセスが急増して色々なところが限界に・・・

  4. ケース1:サーキットブレーカー
 • 認証サービス A からレコメンデーションサービス B を呼んでいる
 • サービス B

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

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


  6. ケース1:サーキットブレーカー
 サービス A の呼出回数 
 サービス B の呼出回数 
 サービス

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

  7. ケース2:誰が遅いのか
 • 認証サービス A から呼んでいるサービス C が遅い
 • セキュリティ関連のサービスなのでスキップするわけにはいかない
 •

    サービス C の遅延ログにもとづいて AP を改善
 • 遅延ログは減ったが、相変わらず遅い!?
 • AP よりも手前の Web サーバーで時間がかかっていた
 
 サービス C のクラウド移行が完了しました! 同僚 0 さん
 エムスリーではオンプレミスのサービスのクラウド移行を進めている
 ちょうどサービス C がクラウドに移行したので、呼び出し先を切替

  8. オンプレミス
 クラウド
 その他
 サービス
 その他
 サービス
 ケース2:誰が遅いのか
 サービス A
 Web


    サーバー
 サービス C
 サービス C
 その他
 サービス
 中から見た性能と
 外から見た性能は
 必ずしも一致しない
 移行前の経路
 
 移行後の経路

  9. ケース3:タイムアウト
 • サービス A の呼び出し元から、タイムアウトになるとの連絡が・・・
 • そんなはずはない!いろいろ改善して性能は十分なはず!
 • 呼び出し元のログをよくよく確認すると
 Timeout

    waiting for connection from pool
 (コネクションプールからの HTTP コネクション取得のタイムアウト)
 • アクセス数の増加により同時接続数も増え、接続が足りなくなっていた
 →呼び出し元の最大接続数を増やして対応
 Read Timeout、Connect Timeout など、様々なタイムアウトがあるので注意

  10. ケース4:誰が遅いのか(再)
 • サービス A の別の呼び出し元からタイムアウトの通知
 • サービス A の応答時間は変わらず問題なし
 •

    クライアント(呼び出し元)の接続設定を変更するも効果なし
 ロードバランサーの SSL 接続上限に達していた
 これサーバーとクライアントの間に LB いますよね !!! 同僚 H さん
 何が遅いのかぜんぜん分からなくて・・・
  11. サービス A の AP サーバーのみクラウド移行する予定だったが、
 急遽 Web サーバーも含めて移行し、ロードバランサーを回避
 オンプレミス
 クラウド


    ケース4:誰が遅いのか(再)
 その他の
 サービス
 ロード
 バランサー
 サービス A
 Web
 サービス A
 Web
 移行前の経路
 
 移行後の経路
 サービス A
 AP
 サービス A
 AP
 方針はシンプルだが Web サーバーには過去の設定が堆積しており・・・ 
 50+

  12. ケース4:誰が遅いのか(再)
 • サービス A の性能問題は解決!!!
 • 残されたロードバランサーも、サービス A や他のサービスがロードバランサーを回 避したことで、接続上限に張り付くことはなくなった


    • めでたしめでたし
 対応前
 対応後

  13. 性能の改善は性能の把握から
 • 外から見た性能
 ◦ Web サーバーや AP サーバーの境界それぞれで測定が必要 
 ◦

    アクセスログを Elasticsearch & Kibana で 
 ▪ In: リクエスト数・Out: 応答時間(パーセンタイル値) 
 ▪ 機能ごと/クライアントごと 
 • 中から見た性能
 ◦ ログ(StopWatch などのタイマーライブラリを利用) 
 • 今回話さなかったもの
 ◦ 分散トレーシング

  14. まとめ
 • 一般的な Web システムの性能問題
 DB:AP:NW = 7 : 2

    : 1 (個人的な経験則)
 エムスリーのサービスの粒度は細かい
 →サービスを細分化すると NW の問題がメインに
 
 • 適切に性能を改善するには、正しい現状把握がだいじ