2022年5月15日(日)に開催されたSRE NEXT 2022 Day 2の登壇資料です。
▼SRE NEXT 2022オフィシャルサイト https://sre-next.dev/2022/
▼発表の概要 https://sre-next.dev/2022/schedule#jp20
© 2022 Nulab, Inc.⻑年運⽤されてきたモノリシックアプリケーションをコンテナ化しようとするとどんな問題に遭遇するか？株式会社ヌーラボサービス開発部 SRE課 吉澤 政洋
View Slide
© 2022 Nulab, Inc.⾃⼰紹介• 吉澤 政洋 (@muziyoshiz)• ヌーラボのテックブログは、ハンドルネームのMuzi（ムジ）名義• 個⼈ブログに過去の記事⼀覧ありhttps://muziyoshiz.hatenablog.com/• Backlogを担当するSite Reliability Engineer (SRE)• メーカーの研究所勤務時にサービス開発および運⽤管理に興味を持ち、転職してWeb系のソフト開発を経験• 2017年8⽉にヌーラボへ⼊社すると同時に、SREへ転⾝• SRE LoungeおよびSRE NEXTスタッフ
© 2022 Nulab, Inc.Backlogとは• オールインワン型のプロジェクト管理ツール• SRE NEXTのプロジェクト管理にも採⽤（ツールスポンサー）• 15年以上の歴史があり、経済産業省やNTTドコモなど国内外に多くのユーザーを持つ• 直感的で誰でも使いやすいユーザーインターフェースを特⻑とし、IT業界に限らず、幅広い業界で導⼊されている
© 2022 Nulab, Inc.今⽇話したいこと• Backlogでは、2019年からAmazon Elastic Kubernetes Service（Amazon EKS）を新規サービスで利⽤し始めている• Backlogを構成するサービスのなかでEC2インスタンス数が⼀番多い、モノリシックなWebアプリケーション（以下、backlog-web）のコンテナ化にチャレンジした• いろいろな問題に苦しめられたが、約1年かけて解決した• どのような問題に遭遇し、それをどう解決したか？
© 2022 Nulab, Inc.Backlogのアーキテクチャ
© 2022 Nulab, Inc.Backlogのアーキテクチャ• Webサーバ、Webアプリケーションサーバ、データベースの3層構成• HTTPリクエストの約9割はbacklog-webが処理NGINX backlog-web(Play Framework)VPC（サービスクラスタ1）Amazon AuroraMySQLその他アプリサーバ1その他アプリサーバ2EC2インスタンス DBインスタンス
© 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サービスクラスタごとにシステム構成や負荷に細かな違いが発⽣
© 2022 Nulab, Inc.Amazon EKSクラスタ• リージョンごとのEKSクラスタを複数サービスクラスタで共⽤• 各サービスクラスタに対応するNamespace上にPodを配置国内リージョンNGINXVPC（サービスクラスタ1）backlog-webVPC（サービスクラスタ2）Amazon EKSクラスタNamespace 1VPC（Amazon EKSクラスタ⽤）Namespace 2Git LFS PodsカンバンボードPodsALB新機能のURLへのリクエストは内部ALB経由でPodにルーティング
© 2022 Nulab, Inc.Amazon EKSクラスタ• コンテナからはbacklog-webと共通のデータベースを参照しており、疎結合なマイクロサービスはまだ実現できていないVPC（サービスクラスタ1）VPC（サービスクラスタ2）Amazon EKSクラスタNamespace 1VPC（Amazon EKSクラスタ⽤）Namespace 2Git LFS PodsカンバンボードPodsAmazon AuroraMySQLCalicoで遮断国内リージョン
© 2022 Nulab, Inc.コンテナ化プロジェクト
© 2022 Nulab, Inc.プロジェクトの概要• 対象• backlog-webのコンテナ化• マイクロサービス化、⾃動スケールアウト・スケールインなども⾏いたいが、まずはコンテナ化して今後の改善を⾏いやすくする• ⽬的• Amazon EKSクラスタを活⽤した、backlog-webの開発効率向上および運⽤コストの削減• Backlogのなかで⼀番難しいアプリにチャレンジし、実現可能性を⽰すことで、社内でのAmazon EKSの活⽤範囲を広げる
© 2022 Nulab, Inc.Platform Engineeringチーム（EKSの運⽤管理）Web Operationチーム（サービス全体の運⽤管理）コンテナ化プロジェクトプロジェクトの体制• ⼩規模なプロジェクト• SRE & プロジェクトマネージャー 1名（Muzi）• 開発者 1〜2名（タスクの多い時期のみ2名）• Kubernetesの知識を持つPlatform Engineeringチームに移籍し、チームメンバーのサポートを受けながら進めたSRE開発者サポート移籍
© 2022 Nulab, Inc.基本⽅針• EC2版と同じコードをPod内のコンテナ上で動作させる• EC2版とコンテナ版を並⾏稼動し、URL単位で段階的に切り替える国内リージョンNGINX(EC2)VPC（サービスクラスタ1）backlog-web(EC2) Amazon EKSクラスタNamespace 1VPC（Amazon EKSクラスタ⽤）backlog-web podsALB少しでも問題が発⽣したらEC2版に切り戻せる
© 2022 Nulab, Inc.当初の計画• コンテナ化の阻害要因をPhase 0で解決してから、コンテナ化事前検証・⾒積もりPhase 0(Preparation)Phase 1(Development)Phase 2(ProductionRelease)専任1名のみプロジェクトの実⾏可否を判断既存のbacklog-webの改修およびEC2インスタンスへのリリースbacklog-webのコンテナ化、運⽤ツールの整備、性能テスト、関連コンポーネントとの結合テストEC2インスタンスからコンテナへの段階的な切り替え当初は2021年7⽉頃に完了の⾒込み
© 2022 Nulab, Inc.実際のスケジュール• 既存アプリケーションの改修が必要な問題が新たに発覚し、Phase 0が延⻑されていった2021/4 7 10 2022/1 4事前検証・⾒積もりPhase 0 (Preparation)Phase 1 (Development)Phase 2(ProductionRelease)
© 2022 Nulab, Inc.私たちが遭遇した問題
© 2022 Nulab, Inc.コンテナ化の主な阻害要因① IPアドレスに頼った認証・認可② ⾃動化を阻害するワークアラウンド③ 永続的なローカルディスクに頼ったGraceful shutdown運⽤でカバーしてたのか…EC2インスタンス前提ならまあそうするよね……
© 2022 Nulab, Inc.① IPアドレスに頼った認証・認可• 関連コンポーネントのなかに、backlog-webのEC2インスタンスのIPアドレスに頼った認証・認可を⾏うものがあったWebDAVサーバApacheport80backlog-webインスタンスのIPアドレスを設定ファイルに持つBasic認証を要求せず、特別な操作を許可Basic認証を要求し、ユーザーに応じたファイル操作を許可NGINX backlog-webX.X.X.XX.X.X.XX.X.X.X
© 2022 Nulab, Inc.解決⽅法• 関連コンポーネント側のコードを改修し、IPアドレスではなくセキュリティグループで認証・認可するように変更WebDAVサーバApacheport80NGINX backlog-webport8081設定ファイルからIPアドレスを削除Apacheモジュールを改修し、内部アクセス⽤のポートを分離このポートへのアクセスをセキュリティグループで限定（コンテナはSecurity Groupsfor Podsを使⽤）
© 2022 Nulab, Inc.関連コンポーネントとの複雑な接続関係• 調査・ヒアリングを繰り返しながら、backlog-webの接続先とそれぞれの認証・認可の⽅法をシステム構成図に記録
© 2022 Nulab, Inc.② ⾃動化を阻害するワークアラウンド1. DBアクセスの負荷分散• EC2インスタンス単位でカスタマイズされた設定が、Podの⾃動追加・削除を阻害2. ウォームアップ処理• 複雑化したウォームアップ処理が、KubernetesのRolling Updateへの置き換えを阻害
© 2022 Nulab, Inc.②-1：DBアクセスの負荷分散• ⼀部の⾼負荷なサービスクラスタでは、Read-only操作の接続先が偏ることでサービス影響が発⽣したため、接続先にDBインスタンスを直接指定していたAmazon Aurora MySQLbacklog-webWriter Reader Reader ReaderRead-onlyEC2インスタンス単位で、接続先DBインスタンスをカスタマイズコスト削減のためWriterの余剰(?)リソースも利⽤
© 2022 Nulab, Inc.Amazon Aurora MySQLbacklog-webRead-only②-1：解決⽅法• MariaDB Connector/Jの”aurora”モードが持つload-balancing reads機能（readerをランダムに選択）の利⽤• Readerインスタンスの増設Writer Reader Reader Reader ReaderReaderインスタンスをランダムに選択し読み取りWriterを読み取りに使わなくなる分を増設
© 2022 Nulab, Inc.②-1：解決⽅法（補⾜）• 残念ながら、2022年1⽉のMariaDB Connector/J 3.0.3 GAで”aurora”モードは廃⽌された• 今後、別⼿段に置き換える必要あり
© 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の待ち時間を⼿動で調整していた
© 2022 Nulab, Inc.②-2：解決⽅法• 新しい/warmupエンドポイントの実装• backlog-webの主要なアクションに対するリクエストを並列実⾏する• 従来は対象アクション1個、並列数1だった• /warmupの呼び出し元は、「/warmupの応答時間がN秒以内」が「M回成功」したときに、⼗分なウォームアップが完了したと判断• つまり、200 OKだけで判断しない• 最適なアクションおよび並列数を決めるための実験• backlog-webの全アクションを呼び出すと時間が⻑くなりすぎる• 本番環境のEC2インスタンスで実験し、なるべく短い時間で⼗分にウォームアップできる落とし所を探した
© 2022 Nulab, Inc.Startup Probeからの/warmupの呼び出し• 「/warmupの応答時間がN秒以内」が「M回成功」という条件判定のため、httpGetの代わりにexecでwarm_up.pyを実⾏• 落とし⽳：successThresholdを1（最⼩値）にしたときの動作• 「1回成功で完了」ではなく、「2回連続で成功したら完了」という意味containers:- name: backlog-webstartupProbe:exec:command: ["/bin/python3.8", "/script/warm_up.py"]successThreshold: 1failureThreshold: 1timeoutSeconds: 600initialDelaySeconds: 10
© 2022 Nulab, Inc.③ 永続的なローカルディスクに頼ったGraceful shutdown• backlog-webのEC2インスタンスで、ローカルディスク（EBSボリューム）をバッファとするプログラムが動作していた1. qmail: 上流のメールサーバへのメール送信2. fluent-bit: 監査ログサービス⽤のログのアップロード• アプリまたはインスタンスがクラッシュしても、EBS上にデータが残り、結果的にデータ⽋損を防げていた• KubernetesのPersistentVolumeでEBSボリュームを使えるが、運⽤が複雑化するため避けたかった
© 2022 Nulab, Inc.③-1：上流のメールサーバへのメール送信• 従来• backlog-webは、ローカルのqmailに対してメールを送信• qmailは、上流のメールサーバに対するリトライ、バッファリング、負荷分散を実施backlog-web (EC2)backlog-webメールサーバ (EC2)qmailEBSVolume上流メールサーバの応答が遅い場合にバッファリトライおよびメール単位の負荷分散
© 2022 Nulab, Inc.③-1：上流のメールサーバへのメール送信• 解決⽅法• メール送信のリトライおよびバッファリングを実装• backlog-webと上流のメールサーバの間にNLBを導⼊• メールN通ごとにコネクションを再確⽴する処理を実装• NLBはコネクションを振り分ける（メール単位の振り分けではない）ためbacklog-web (EC2) メールサーバ (EC2)backlog-webNetwork LoadBalancer (NLB)コネクション単位の負荷分散リトライおよび定期的なコネクション再確⽴メールキューキューから溢れたメールはOOMを防ぐために破棄
© 2022 Nulab, Inc.③-2：S3への監査ログのアップロード• 従来• fluent-bitは、監査ログを出⼒するファイルを監視• 10分ごと、または⼀定サイズごとにS3へアップロードbacklog-web (EC2)Nulab Pass監査ログ⽤S3バケット10分ごとbacklog-web監査ログファイルfluent-bitバッファ
© 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 DataFirehose配信ストリーム60秒ごと 10分ごと
© 2022 Nulab, Inc.Graceful shutdownの改修• AkkaのCoordinated Shutdownを利⽤して、メモリ上のメールおよび監査ログの出⼒が終わるまで待つ処理を追加• Graceful shutdown終了時に空ファイルを出⼒する処理を追加• このファイルをfluentdサイドカーから監視して、必ずbacklog-web pod→fluentdサイドカーの順にGraceful shutdownすることで、監査ログの⽋損を防⽌
© 2022 Nulab, Inc.コンテナ化の主な阻害要因のふりかえり① IPアドレスに頼った認証・認可② ⾃動化を阻害するワークアラウンド③ 永続的なローカルディスクに頼ったGraceful shutdown• 阻害要因①〜②の解決により、コンテナ化が進むだけでなく、EC2インスタンス版の運⽤も楽になった• 阻害要因③はコンテナ化に固有のもので、その⼀部は、開発チームとうまく連携できていれば避けることができた• コンテナ化と並⾏していた監査ログサービスの開発（2021年12⽉リリース）との連携不⾜で、⼿戻りが発⽣したのが反省事項
© 2022 Nulab, Inc.おわりに
© 2022 Nulab, Inc.コンテナ化の先に⾒据える理想像• 開発効率向上• 開発チームのための、新サービス構築・運⽤のセルフサービス化• モノリシックなbacklog-webの、複数のサービスへの分割（開発チーム単位での分割）• 運⽤コストの低減• サービスレベルに基づく⾃動スケールアウト・スケールイン• backlog-webは多数の機能を含むモノリシックアプリケーションのため、どのサービスレベル指標（SLI）に基づいて⾃動化すべきかの判断が難しい• backlog-web以外のアプリケーションのコンテナ化
© 2022 Nulab, Inc.We are hiring!• 共にこれらの改善に取り組んでくれるメンバーを募集中• SRE NEXTオフィシャルサイトのウェブボードのOTHER欄（ツールスポンサー）に、採⽤情報を掲載しています！
© 2022 Nulab, Inc.まとめ• Backlogを構成するサービスのなかで最もEC2インスタンス数の多いモノリシックなWebアプリケーションのコンテナ化にチャレンジした• コンテナ化のために必要な作業の⼤半は、既存のアプリケーションの問題を洗い出して改修し、コンテナ化の阻害要因をなくすことだった• 現在はEC2版とコンテナ版を並⾏稼動中のため、コンテナ化が完了した際には、改めて知⾒をまとめ、ヌーラボのテックブログなどを通して共有したい
nulabinc
masa5555
yuya4
minorun365
sat
fujiwara3
murachiakira
yuj1osm
kojira
orgachem
shibuiwilliam
oldbigbuddha
toshi0383
lara
cromwellryan
jcasabona
morganepeng
chrisshort
keavy
eileencodes
stephaniewalter
chrislema
skipperchong
jmmastey