長年運用されてきたモノリシックアプリケーションをコンテナ化しようとするとどんな問題に遭遇するか？ / SRE NEXT 2022

Transcript

1. © 2022 Nulab, Inc. ⻑年運⽤されてきた モノリシックアプリケーションを コンテナ化しようとすると どんな問題に遭遇するか？ 株式会社ヌーラボ サービス開発部

   SRE課 吉澤 政洋

2. © 2022 Nulab, Inc. ⾃⼰紹介 • 吉澤 政洋 (@muziyoshiz) •

   ヌーラボのテックブログは、ハンドルネームのMuzi（ムジ）名義 • 個⼈ブログに過去の記事⼀覧あり https://muziyoshiz.hatenablog.com/ • Backlogを担当するSite Reliability Engineer (SRE) • メーカーの研究所勤務時にサービス開発および運⽤管理に興味を持ち、 転職してWeb系のソフト開発を経験 • 2017年8⽉にヌーラボへ⼊社すると同時に、SREへ転⾝ • SRE LoungeおよびSRE NEXTスタッフ 

3. © 2022 Nulab, Inc. Backlogとは • オールインワン型のプロジェクト管理ツール • SRE NEXTのプロジェクト管理にも採⽤（ツールスポンサー）

   • 15年以上の歴史があり、 経済産業省やNTTドコモなど 国内外に多くのユーザーを持つ • 直感的で誰でも使いやすい ユーザーインターフェースを 特⻑とし、IT業界に限らず、 幅広い業界で導⼊されている 

4. © 2022 Nulab, Inc. 今⽇話したいこと • Backlogでは、2019年からAmazon Elastic Kubernetes Service

   （Amazon EKS）を新規サービスで利⽤し始めている • Backlogを構成するサービスのなかでEC2インスタンス数が ⼀番多い、モノリシックなWebアプリケーション （以下、backlog-web）のコンテナ化にチャレンジした • いろいろな問題に苦しめられたが、約1年かけて解決した • どのような問題に遭遇し、それをどう解決したか？ 

5. © 2022 Nulab, Inc. Backlogのアーキテクチャ

6. © 2022 Nulab, Inc. Backlogのアーキテクチャ • Webサーバ、Webアプリケーションサーバ、データベースの3層構成 • HTTPリクエストの約9割はbacklog-webが処理 

   NGINX backlog-web (Play Framework) VPC（サービスクラスタ1） Amazon Aurora MySQL その他アプリサーバ1 その他アプリサーバ2 EC2インスタンス DBインスタンス

7. © 2022 Nulab, Inc. Backlogのアーキテクチャ • サービスクラスタを複数並べることでスペース（顧客）収容数を増加  国内リージョン 海外リージョン

   VPC（サービスクラスタ1） VPC（サービスクラスタ2） VPC（サービスクラスタ3） VPC（サービスクラスタ4） VPC（サービスクラスタ5） VPC（サービスクラスタ6） スペース1 スペース2 スペース3 スペース4 スペース5 スペース6 スペース7 スペースA スペースB スペースC サービスクラスタごとに システム構成や負荷に 細かな違いが発⽣

8. © 2022 Nulab, Inc. Amazon EKSクラスタ • リージョンごとのEKSクラスタを複数サービスクラスタで共⽤ • 各サービスクラスタに対応するNamespace上にPodを配置

    国内リージョン NGINX VPC（サービスクラスタ1） backlog-web VPC（サービスクラスタ2） Amazon EKSクラスタ Namespace 1 VPC（Amazon EKSクラスタ⽤） Namespace 2 Git LFS Pods カンバンボードPods ALB 新機能のURLへのリクエストは 内部ALB経由でPodにルーティング

9. © 2022 Nulab, Inc. Amazon EKSクラスタ • コンテナからはbacklog-webと共通のデータベースを参照しており、 疎結合なマイクロサービスはまだ実現できていない 

   VPC（サービスクラスタ1） VPC（サービスクラスタ2） Amazon EKSクラスタ Namespace 1 VPC（Amazon EKSクラスタ⽤） Namespace 2 Git LFS Pods カンバンボードPods Amazon Aurora MySQL Calicoで 遮断 国内リージョン

10. © 2022 Nulab, Inc. コンテナ化プロジェクト

11. © 2022 Nulab, Inc. プロジェクトの概要 • 対象 • backlog-webのコンテナ化 •

    マイクロサービス化、⾃動スケールアウト・スケールインなども⾏いたいが、 まずはコンテナ化して今後の改善を⾏いやすくする • ⽬的 • Amazon EKSクラスタを活⽤した、backlog-webの開発効率向上 および運⽤コストの削減 • Backlogのなかで⼀番難しいアプリにチャレンジし、実現可能性を⽰すことで、 社内でのAmazon EKSの活⽤範囲を広げる 

12. © 2022 Nulab, Inc. Platform Engineeringチーム （EKSの運⽤管理） Web Operationチーム （サービス全体の運⽤管理）

    コンテナ化 プロジェクト プロジェクトの体制 • ⼩規模なプロジェクト • SRE & プロジェクトマネージャー 1名（Muzi） • 開発者 1〜2名（タスクの多い時期のみ2名） • Kubernetesの知識を持つPlatform Engineeringチームに移籍し、 チームメンバーのサポートを受けながら進めた  SRE 開発者 サポート 移籍

13. © 2022 Nulab, Inc. 基本⽅針 • EC2版と同じコードをPod内のコンテナ上で動作させる • EC2版とコンテナ版を並⾏稼動し、URL単位で段階的に切り替える 

    国内リージョン NGINX (EC2) VPC（サービスクラスタ1） backlog-web (EC2) Amazon EKSクラスタ Namespace 1 VPC（Amazon EKSクラスタ⽤） backlog-web pods ALB 少しでも問題が発⽣したら EC2版に切り戻せる

14. © 2022 Nulab, Inc. 当初の計画 • コンテナ化の阻害要因をPhase 0で解決してから、コンテナ化  事前検証・

    ⾒積もり Phase 0 (Preparation) Phase 1 (Development) Phase 2 (Production Release) 専任1名のみ プロジェクトの 実⾏可否を判断 既存のbacklog- webの改修および EC2インスタンス へのリリース backlog-webのコンテナ化、 運⽤ツールの整備、性能テス ト、関連コンポーネントとの 結合テスト EC2インスタンス からコンテナへの 段階的な切り替え 当初は2021年7⽉ 頃に完了の⾒込み

15. © 2022 Nulab, Inc. 実際のスケジュール • 既存アプリケーションの改修が必要な問題が新たに発覚し、 Phase 0が延⻑されていった 

    2021/4 7 10 2022/1 4 事前検証・ ⾒積もり Phase 0 (Preparation) Phase 1 (Development) Phase 2 (Production Release)

16. © 2022 Nulab, Inc. 私たちが遭遇した問題

17. © 2022 Nulab, Inc. コンテナ化の主な阻害要因 ① IPアドレスに頼った認証・認可 ② ⾃動化を阻害するワークアラウンド ③

    永続的なローカルディスクに頼ったGraceful shutdown  運⽤でカバー してたのか… EC2インスタンス前提なら まあそうするよね……

18. © 2022 Nulab, Inc. ① IPアドレスに頼った認証・認可 • 関連コンポーネントのなかに、backlog-webのEC2インスタンス のIPアドレスに頼った認証・認可を⾏うものがあった 

    WebDAVサーバ Apache port 80 backlog-webインスタンスの IPアドレスを設定ファイルに持つ Basic認証を要求 せず、特別な操作 を許可 Basic認証を要求し、ユーザーに 応じたファイル操作を許可 NGINX backlog-web X.X.X.X X.X.X.X X.X.X.X

19. © 2022 Nulab, Inc. 解決⽅法 • 関連コンポーネント側のコードを改修し、IPアドレスではなく セキュリティグループで認証・認可するように変更  WebDAVサーバ

    Apache port 80 NGINX backlog-web port 8081 設定ファイルから IPアドレスを削除 Apacheモジュールを 改修し、内部アクセス ⽤のポートを分離 このポートへのアクセスを セキュリティグループで限定 （コンテナはSecurity Groups for Podsを使⽤）

20. © 2022 Nulab, Inc. 関連コンポーネントとの複雑な接続関係 • 調査・ヒアリングを繰り返しながら、backlog-webの接続先と それぞれの認証・認可の⽅法をシステム構成図に記録 

21. © 2022 Nulab, Inc. ② ⾃動化を阻害するワークアラウンド 1. DBアクセスの負荷分散 • EC2インスタンス単位でカスタマイズされた設定が、

    Podの⾃動追加・削除を阻害 2. ウォームアップ処理 • 複雑化したウォームアップ処理が、 KubernetesのRolling Updateへの置き換えを阻害 

22. © 2022 Nulab, Inc. ②-1：DBアクセスの負荷分散 • ⼀部の⾼負荷なサービスクラスタでは、 Read-only操作の接続先が偏ることでサービス影響が発⽣した ため、接続先にDBインスタンスを直接指定していた 

    Amazon Aurora MySQL backlog-web Writer Reader Reader Reader Read-only EC2インスタンス単位 で、接続先DBインス タンスをカスタマイズ コスト削減のため Writerの余剰(?) リソースも利⽤

23. © 2022 Nulab, Inc. Amazon Aurora MySQL backlog-web Read-only ②-1：解決⽅法

    • MariaDB Connector/Jの”aurora”モードが持つ load-balancing reads機能（readerをランダムに選択）の利⽤ • Readerインスタンスの増設  Writer Reader Reader Reader Reader Readerインスタンス をランダムに選択し 読み取り Writerを読み取り に使わなくなる分 を増設

24. © 2022 Nulab, Inc. ②-1：解決⽅法（補⾜） • 残念ながら、2022年1⽉のMariaDB Connector/J 3.0.3 GAで

    ”aurora”モードは廃⽌された • 今後、別⼿段に置き換える必要あり 

25. © 2022 Nulab, Inc. ②-2：ウォームアップ処理 • 従来のbacklog-webのローリングアップデート 1. Webサーバ上のnginx.confを更新し、upstreamから外す 2.

    インスタンス上の実⾏ファイルをアップデート 3. インスタンス上でcurlを実⾏し、ウォームアップリクエストを送信 4. Webサーバ上のnginx.confを更新し、upstreamに追加し直す 5. 実トラフィックを数分間流す • ⼿順3では応答時間が⼗分早くならないため、⼿順5が必要 • ⼿順5を省略して次のインスタンスに進むと、⾼負荷なサービス クラスタではbacklog-webサービス全体の応答時間が悪化 • リリース時間短縮のため、⼿順5の待ち時間を⼿動で調整していた 

26. © 2022 Nulab, Inc. ②-2：解決⽅法 • 新しい/warmupエンドポイントの実装 • backlog-webの主要なアクションに対するリクエストを並列実⾏する •

    従来は対象アクション1個、並列数1だった • /warmupの呼び出し元は、「/warmupの応答時間がN秒以内」が 「M回成功」したときに、⼗分なウォームアップが完了したと判断 • つまり、200 OKだけで判断しない • 最適なアクションおよび並列数を決めるための実験 • backlog-webの全アクションを呼び出すと時間が⻑くなりすぎる • 本番環境のEC2インスタンスで実験し、なるべく短い時間で⼗分に ウォームアップできる落とし所を探した 

27. © 2022 Nulab, Inc. Startup Probeからの/warmupの呼び出し • 「/warmupの応答時間がN秒以内」が「M回成功」という条件 判定のため、httpGetの代わりにexecでwarm_up.pyを実⾏ •

    落とし⽳：successThresholdを1（最⼩値）にしたときの動作 • 「1回成功で完了」ではなく、「2回連続で成功したら完了」という意味  containers: - name: backlog-web startupProbe: exec: command: ["/bin/python3.8", "/script/warm_up.py"] successThreshold: 1 failureThreshold: 1 timeoutSeconds: 600 initialDelaySeconds: 10

28. © 2022 Nulab, Inc. ③ 永続的なローカルディスクに頼った Graceful shutdown • backlog-webのEC2インスタンスで、ローカルディスク（EBS

    ボリューム）をバッファとするプログラムが動作していた 1. qmail: 上流のメールサーバへのメール送信 2. fluent-bit: 監査ログサービス⽤のログのアップロード • アプリまたはインスタンスがクラッシュしても、 EBS上にデータが残り、結果的にデータ⽋損を防げていた • KubernetesのPersistentVolumeでEBSボリュームを使えるが、 運⽤が複雑化するため避けたかった 

29. © 2022 Nulab, Inc. ③-1：上流のメールサーバへのメール送信 • 従来 • backlog-webは、ローカルのqmailに対してメールを送信 •

    qmailは、上流のメールサーバに対するリトライ、バッファリング、 負荷分散を実施  backlog-web (EC2) backlog- web メールサーバ (EC2) qmail EBS Volume 上流メールサーバの応答が 遅い場合にバッファ リトライおよびメール 単位の負荷分散

30. © 2022 Nulab, Inc. ③-1：上流のメールサーバへのメール送信 • 解決⽅法 • メール送信のリトライおよびバッファリングを実装 •

    backlog-webと上流のメールサーバの間にNLBを導⼊ • メールN通ごとにコネクションを再確⽴する処理を実装 • NLBはコネクションを振り分ける（メール単位の振り分けではない）ため  backlog-web (EC2) メールサーバ (EC2) backlog-web Network Load Balancer (NLB) コネクション単位 の負荷分散 リトライおよび定期的 なコネクション再確⽴ メールキュー キューから溢れたメールは OOMを防ぐために破棄

31. © 2022 Nulab, Inc. ③-2：S3への監査ログのアップロード • 従来 • fluent-bitは、監査ログを出⼒するファイルを監視 •

    10分ごと、または⼀定サイズごとにS3へアップロード  backlog-web (EC2) Nulab Pass 監査ログ⽤ S3バケット 10分ごと backlog-web 監査ログ ファイル fluent-bit バッファ

32. © 2022 Nulab, Inc. backlog-web pod ③-2：S3への監査ログのアップロード • 解決⽅法 •

    fluentdサイドカーが、監査ログファイルを監視 • fluent-bitにはKinesisとの連携に不具合があったため、fluentdを採⽤ • 60秒ごと、または⼀定サイズごとにAmazon Kinesis Data Firehose 配信ストリーム（S3を送信先に設定）へアップロード  backlog-web コンテナ Nulab Pass 監査ログ⽤ S3バケット 監査ログ ファイル fluentd サイドカー バッファ Kinesis Data Firehose 配信ストリーム 60秒ごと 10分ごと

33. © 2022 Nulab, Inc. Graceful shutdownの改修 • AkkaのCoordinated Shutdownを利⽤して、メモリ上のメール および監査ログの出⼒が終わるまで待つ処理を追加

    • Graceful shutdown終了時に空ファイルを出⼒する処理を追加 • このファイルをfluentdサイドカーから監視して、 必ずbacklog-web pod→fluentdサイドカーの順にGraceful shutdown することで、監査ログの⽋損を防⽌ 

34. © 2022 Nulab, Inc. コンテナ化の主な阻害要因のふりかえり ① IPアドレスに頼った認証・認可 ② ⾃動化を阻害するワークアラウンド ③

    永続的なローカルディスクに頼ったGraceful shutdown • 阻害要因①〜②の解決により、コンテナ化が進むだけでなく、 EC2インスタンス版の運⽤も楽になった • 阻害要因③はコンテナ化に固有のもので、その⼀部は、 開発チームとうまく連携できていれば避けることができた • コンテナ化と並⾏していた監査ログサービスの開発（2021年12⽉ リリース）との連携不⾜で、⼿戻りが発⽣したのが反省事項 

35. © 2022 Nulab, Inc. おわりに

36. © 2022 Nulab, Inc. コンテナ化の先に⾒据える理想像 • 開発効率向上 • 開発チームのための、新サービス構築・運⽤のセルフサービス化 •

    モノリシックなbacklog-webの、複数のサービスへの分割 （開発チーム単位での分割） • 運⽤コストの低減 • サービスレベルに基づく⾃動スケールアウト・スケールイン • backlog-webは多数の機能を含むモノリシックアプリケーションのため、 どのサービスレベル指標（SLI）に基づいて⾃動化すべきかの判断が難しい • backlog-web以外のアプリケーションのコンテナ化 

37. © 2022 Nulab, Inc. We are hiring! • 共にこれらの改善に取り組んでくれるメンバーを募集中 •

    SRE NEXTオフィシャルサイトのウェブボードのOTHER欄 （ツールスポンサー）に、採⽤情報を掲載しています！ 

38. © 2022 Nulab, Inc. まとめ • Backlogを構成するサービスのなかで 最もEC2インスタンス数の多い モノリシックなWebアプリケーションのコンテナ化に チャレンジした

    • コンテナ化のために必要な作業の⼤半は、 既存のアプリケーションの問題を洗い出して改修し、 コンテナ化の阻害要因をなくすことだった • 現在はEC2版とコンテナ版を並⾏稼動中のため、 コンテナ化が完了した際には、改めて知⾒をまとめ、 ヌーラボのテックブログなどを通して共有したい