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


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


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


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


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


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


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


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


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


ケース４：誰が遅いのか（再）
 ● サービス A の別の呼び出し元からタイムアウトの通知
 ● サービス A の応答時間は変わらず問題なし
 ● クライアント（呼び出し元）の接続設定を変更するも効果なし
 ロードバランサーの SSL 接続上限に達していた
 これサーバーとクライアントの間に LB いますよね ！！！ 同僚 H さん
 何が遅いのかぜんぜん分からなくて・・・

サービス A の AP サーバーのみクラウド移行する予定だったが、
 急遽 Web サーバーも含めて移行し、ロードバランサーを回避
 オンプレミス
 クラウド
 ケース４：誰が遅いのか（再）
 その他の
 サービス
 ロード
 バランサー
 サービス A
 Web
 サービス A
 Web
 移行前の経路
 
 移行後の経路
 サービス A
 AP
 サービス A
 AP
 方針はシンプルだが Web サーバーには過去の設定が堆積しており・・・ 
 50+


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


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


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