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

Slide 1

Slide 1 text

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

Slide 6

Slide 6 text

© 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インスタンス

Slide 7

Slide 7 text

© 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 サービスクラスタごとにシステム構成や負荷に細かな違いが発⽣

Slide 8

Slide 8 text

© 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にルーティング

Slide 9

Slide 9 text

© 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で遮断国内リージョン

Slide 10

Slide 10 text

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

© 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版に切り戻せる

Slide 14

Slide 14 text

© 2022 Nulab, Inc. 当初の計画 • コンテナ化の阻害要因をPhase 0で解決してから、コンテナ化事前検証・⾒積もり Phase 0 (Preparation) Phase 1 (Development) Phase 2 (Production Release) 専任1名のみプロジェクトの実⾏可否を判断既存のbacklog- webの改修および EC2インスタンスへのリリース backlog-webのコンテナ化、運⽤ツールの整備、性能テスト、関連コンポーネントとの結合テスト EC2インスタンスからコンテナへの段階的な切り替え当初は2021年7⽉頃に完了の⾒込み

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

© 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

Slide 19

Slide 19 text

© 2022 Nulab, Inc. 解決⽅法 • 関連コンポーネント側のコードを改修し、IPアドレスではなくセキュリティグループで認証・認可するように変更 WebDAVサーバ Apache port 80 NGINX backlog-web port 8081 設定ファイルから IPアドレスを削除 Apacheモジュールを改修し、内部アクセス⽤のポートを分離このポートへのアクセスをセキュリティグループで限定（コンテナはSecurity Groups for Podsを使⽤）

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

© 2022 Nulab, Inc. ②-1：DBアクセスの負荷分散 • ⼀部の⾼負荷なサービスクラスタでは、 Read-only操作の接続先が偏ることでサービス影響が発⽣したため、接続先にDBインスタンスを直接指定していた Amazon Aurora MySQL backlog-web Writer Reader Reader Reader Read-only EC2インスタンス単位で、接続先DBインスタンスをカスタマイズコスト削減のため Writerの余剰(?) リソースも利⽤

Slide 23

Slide 23 text

© 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を読み取りに使わなくなる分を増設

Slide 24

Slide 24 text

Slide 25

Slide 25 text

© 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の待ち時間を⼿動で調整していた

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

© 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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

© 2022 Nulab, Inc. ③-1：上流のメールサーバへのメール送信 • 従来 • backlog-webは、ローカルのqmailに対してメールを送信 • qmailは、上流のメールサーバに対するリトライ、バッファリング、負荷分散を実施 backlog-web (EC2) backlog- web メールサーバ (EC2) qmail EBS Volume 上流メールサーバの応答が遅い場合にバッファリトライおよびメール単位の負荷分散

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

Slide 32

Slide 32 text

© 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分ごと

Slide 33

Slide 33 text

© 2022 Nulab, Inc. Graceful shutdownの改修 • AkkaのCoordinated Shutdownを利⽤して、メモリ上のメールおよび監査ログの出⼒が終わるまで待つ処理を追加 • Graceful shutdown終了時に空ファイルを出⼒する処理を追加 • このファイルをfluentdサイドカーから監視して、必ずbacklog-web pod→fluentdサイドカーの順にGraceful shutdown することで、監査ログの⽋損を防⽌

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

Slide 36

Slide 36 text

© 2022 Nulab, Inc. コンテナ化の先に⾒据える理想像 • 開発効率向上 • 開発チームのための、新サービス構築・運⽤のセルフサービス化 • モノリシックなbacklog-webの、複数のサービスへの分割（開発チーム単位での分割） • 運⽤コストの低減 • サービスレベルに基づく⾃動スケールアウト・スケールイン • backlog-webは多数の機能を含むモノリシックアプリケーションのため、どのサービスレベル指標（SLI）に基づいて⾃動化すべきかの判断が難しい • backlog-web以外のアプリケーションのコンテナ化

Slide 37

Slide 37 text

Slide 38

Slide 38 text

© 2022 Nulab, Inc. まとめ • Backlogを構成するサービスのなかで最もEC2インスタンス数の多いモノリシックなWebアプリケーションのコンテナ化にチャレンジした • コンテナ化のために必要な作業の⼤半は、既存のアプリケーションの問題を洗い出して改修し、コンテナ化の阻害要因をなくすことだった • 現在はEC2版とコンテナ版を並⾏稼動中のため、コンテナ化が完了した際には、改めて知⾒をまとめ、ヌーラボのテックブログなどを通して共有したい