Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

2022年5月15日(日)に開催されたSRE NEXT 2022 Day 2の登壇資料です。

▼SRE NEXT 2022オフィシャルサイト
https://sre-next.dev/2022/

▼発表の概要
https://sre-next.dev/2022/schedule#jp20

3e77f9dbec6a87756d1dbdddab283aee?s=128

Nulab Inc.
PRO

May 15, 2022
Tweet

More Decks by Nulab Inc.

Other Decks in Technology

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版とコンテナ版を並⾏稼動中のため、 コンテナ化が完了した際には、改めて知⾒をまとめ、 ヌーラボのテックブログなどを通して共有したい