レガシー共有バッチ基盤への挑戦 SREドリブンなリアーキテクチャリングの取り組み / Tackling the Legacy Shared Batch Infrastructure: An SRE-Driven Re-architecting Initiative

Transcript

1. レガシー共有バッチ基盤への挑戦 SREドリブンなリアーキテクチャリングの取り組み 2026年1月31日 株式会社コドモン 小西達大 SRE Kaigi 2026
2. 2 経歴 前職でアプリケーションエンジニアとして従事後、 株式会社コドモンのSREチームにジョイン。 大阪在住。 自己紹介 小西 達大 こにし たつひろ
3. 3 パパママと、子どもとの時間に 1秒でも多くの笑顔と愛情を すべての先生に 子どもと向き合う時間と心のゆとりを 「保育・子育て」と 社会をつなげる 保護者の子育てへの伴走 保育・教育者の環境改善 子育ての社会インフラ作り 子どもを取り巻く環境を テクノロジーの力で よりよいものに ミッション 私たちの使命
4. すべての先生に 子どもと向き合う 時間と心のゆとりを こんなプロダクトを開発しています メインプロダクトは、こども施設職員の業務を支援するWebアプリケーション。 保護者と施設のやり取りを支えるモバイルアプリケーションや、施設職員向けモバイル版 アプリケーション、外部サービスと連携するAPIなども開発しています。 4
6. 6 目次 1. コドモンSREチームの取り組み 2. リアーキテクチャリングはじめの一歩 3. システムの信頼性を向上するための設計・実装のポイント 4. 安全なローンチのために取り組んだこと 5. まとめ
7. 7 目次 1. コドモンSREチームの取り組み 2. リアーキテクチャリングはじめの一歩 3. システムの信頼性を向上するための設計・実装のポイント 4. 安全なローンチのために取り組んだこと 5. まとめ
8. UI/UXデザイナー プロダクトセキュリティ エンジニア・QA プロダクトマネージャー 新規事業 チーム 1チームは関連する複数の機能を担当 技術戦略 計9名 計48名 計9名 計5名 計8名 コドモン開発チーム編成 8 SRE 計5名 … … 他 数チーム 組 織 横 断 チ ｜ ム … メンバー … マネージャー zzz機能 チーム yyy機能 チーム xxx機能 チーム … … …
9. 9 CONFIDENTIAL - © 2022 CoDMON Inc. 9 SREチームのミッション 開発者の認知負荷を減らして 開発・運用が自己完結できる環境を提供する • 開発チームが自律的に運用するのを手助けする • 開発チームの認知不可を減らし、生産性を上げるためのプラットフォームを提供する
10. 10 CONFIDENTIAL - © 2022 CoDMON Inc. 10 SREチームの取り組み • プロダクト全体における技術スタックとインフラ構成の標準化を推進 ◦ アプリケーション実行基盤の統一（コンテナ化） ◦ CI/CDフローの整備
11. 11 CONFIDENTIAL - © 2022 CoDMON Inc. 11 コドモンシステムの現在地 • インフラ構成の標準化推進により、大半のアプリケーション実行基盤はECS によるコンテナ環境で統一されている • 一方、EC2で動いているBatchサーバーは手付かずのまま残っている
12. 12 CONFIDENTIAL - © 2022 CoDMON Inc. 12 バッチサーバーのコンテナ化に取りかかろうとするが... OS（Amazon Linux 2）のサポート終了案内を契機に、バッチサーバーについて もコンテナ化に取り掛かろうとするが... • ブラックボックス化しつつあり、構成が不明瞭 ◦ 構成管理はSREに依存。一方、構成に詳しいエン ジニアは既に離任 ◦ 可観測性が低く、時より原因不明のエラーが発生 する • 改修に伴う影響範囲・影響度は大きい ◦ 複数の開発チームが、管轄の処理を動かしてお り、サービス的に重要な処理も動いている
13. 13 CONFIDENTIAL - © 2022 CoDMON Inc. 13 バッチサーバーのコンテナ化に取りかかろうとするが... OS（Amazon Linux 2）のサポート終了案内を契機に、バッチサーバーについて もコンテナ化に取り掛かろうとするが... • ブラックボックス化しつつあり、構成が不明瞭 ◦ 構成管理はSREに依存。一方、構成に詳しいエン ジニアは既に離任 ◦ 可観測性が低く、時より原因不明のエラーが発生 する • 改修に伴う影響範囲・影響度は大きい ◦ 複数の開発チームが、管轄の処理を動かしてお り、サービス的に重要な処理も動いている 一筋縄では行かなそう...
14. 14 CONFIDENTIAL - © 2022 CoDMON Inc. 14 今日お話ししたいこと • （レガシー化しつつある）バッチサーバーをコンテナ化する際のポイント • 「影響範囲が広く重要度が高い」一方で「ブラックボックス化しつつある」 インフラ基盤を「SREが主導して」リアーキテクチャリングする手法
15. 15 目次 1. コドモンSREチームの取り組み 2. リアーキテクチャリングはじめの一歩 3. システムの信頼性を向上するための設計・実装のポイント 4. 安全なローンチのために取り組んだこと 5. まとめ
16. 16 CONFIDENTIAL - © 2022 CoDMON Inc. 16 バッチサーバーの課題 • ブラックボックス化しつつあり、構成が不明瞭 • 改修に伴う影響範囲・影響度は大きい どこから手を付ければ良いか分からない...
17. 17 CONFIDENTIAL - © 2022 CoDMON Inc. 17 バッチサーバーの課題 • ブラックボックス化しつつあり、構成が不明瞭 • 改修に伴う影響範囲・影響度は大きい どこから手を付ければ良いか分からない... ↓ • まずは現状の構成を把握し、見通しを良くする • 得られた情報からシステム要件を洗い出し、リアーキテクチャリングの方針 を立てる
18. 18 CONFIDENTIAL - © 2022 CoDMON Inc. 18 構成把握のために実施したこと 1. 何はともあれ情報収集 2. 得られた情報を構成図に集約し、チーム内で共有しあう 3. 各バッチ処理の担当チームにヒアリング
19. 19 CONFIDENTIAL - © 2022 CoDMON Inc. 19 構成把握のために実施したこと 1. 何はともあれ情報収集 2. 得られた情報を構成図に集約し、チーム内で共有しあう 3. 各バッチ処理の担当チームにヒアリング
20. 20 CONFIDENTIAL - © 2022 CoDMON Inc. 20 1：何はともあれ情報収集 • インフラ設計書や構成図・IaCのコードはもちろん有用な情報 • 一方、更新されていない / そもそも存在しない というケースもあるので、そ れだけに頼らず実環境・実運用からも情報収集する。 • たとえば、以下の情報源から有用な情報を得ることができる ◦ プロダクション環境のリバースエンジニアリング ◦ 過去のエラー対応 ◦ アプリケーションのコード
21. 21 CONFIDENTIAL - © 2022 CoDMON Inc. 21 プロダクション環境のリバースエンジニアリング • 実際に動いている環境から情報収集する ◦ 動いているプロセス / 動いているcron / インストールされたパッケージ / ファイルパーミッション / プログラミング言語設定情報 … ◦ 例) コード管理されていると思っていたcrontabファイルが実際には使わ れておらず、インスタンス内で直接crontabを更新する運用だった
22. 22 CONFIDENTIAL - © 2022 CoDMON Inc. 22 過去のエラー対応 • 過去のアラート対応 ◦ 処理が失敗した場合の影響度 ◦ リカバリ対応手順の有無 • 過去のポストモーテム ◦ 過去発生した問題：要件把握 ◦ 実施した対処：構成理解
23. 23 CONFIDENTIAL - © 2022 CoDMON Inc. 23 アプリケーションのコード • コードの詳細まで完璧に理解する必要はないが、AIを用いるなどしてざっく りと流れを掴む • 冒頭 / 末尾 で実施されている共通処理や、外部リソースとの通信部分に着目 することで、アプリケーション <> インフラ 間の接点の理解に繋がる ◦ 例) 処理の冒頭で空ファイルを作成。以降の処理ではファイルの存在判 定を行うことにより、多重起動を防止する構成となっていた
24. 24 CONFIDENTIAL - © 2022 CoDMON Inc. 24 構成把握のために実施したこと 1. 何はともあれ情報収集 2. 得られた情報を構成図に集約し、チーム内で共有しあう 3. 各バッチ処理の担当チームにヒアリング
25. 25 CONFIDENTIAL - © 2022 CoDMON Inc. 25 2：得られた情報を構成図に集約し、チーム内で共有しあう • 収集した情報を元に、構成図を作成する • 構成図作成はSREメンバー各々で実施し、チーム内で共有しあう ◦ 複数人の視点を介することによって、構成の解像度を上げる
26. 26 CONFIDENTIAL - © 2022 CoDMON Inc. 26 構成把握のために実施したこと 1. 何はともあれ情報収集 2. 得られた情報を構成図に集約し、チーム内で共有しあう 3. 各バッチ処理の担当チームにヒアリング
27. 27 CONFIDENTIAL - © 2022 CoDMON Inc. 27 3：各バッチ処理の担当チームにヒアリング • 担当チームが不明の処理もあったので、まずはバッチ処理毎の担当チームを 明確化 • 各担当チームに、バッチ処理毎の特性や処理内容をヒアリングする
28. 28 CONFIDENTIAL - © 2022 CoDMON Inc. 28 3：各バッチ処理の担当チームにヒアリング • ヒアリングを行う目的 ◦ 各処理毎の詳細な情報収集 ◦ 各担当チームとの関係性作り • SREチーム側である程度の情報収集を行ってからヒアリングを実施した理由 ◦ 事前に情報収集した情報を元に「質問」だけではなく「議論」をするこ とで、得られる情報の精度を高めることができるため
29. 29 CONFIDENTIAL - © 2022 CoDMON Inc. 29 システムに必要な要件を洗い出す • 得られた情報を元に、バッチサーバーに求められる要件を洗い出す • 要件を満たせるように、リアーキテクチャリングの方針を立てる
30. 30 目次 1. コドモンSREチームの取り組み 2. リアーキテクチャリングはじめの一歩 3. システムの信頼性を向上するための設計・実装のポイント 4. 安全なローンチのために取り組んだこと 5. まとめ
31. 31 CONFIDENTIAL - © 2022 CoDMON Inc. 31 バッチサーバーに必要な要件
32. 32 CONFIDENTIAL - © 2022 CoDMON Inc. 32 論点となりうる要件 • デプロイ前後で実行中の処理が中断されないこと • 短い間隔の処理を滞りなく実行可能であること
33. 33 CONFIDENTIAL - © 2022 CoDMON Inc. 33 デプロイ前後で実行中の処理が中断されないこと • バッチサーバーのデプロイは1日2回（業務時間 中）実施され、この際に実行中だった処理が中断す ることは許容されない • ECS化 & ENTRYPOINTでcronを稼働する方式だ と、デプロイ時に旧タスクが落ちるタイミングで実 行中だった処理も中断されてしまう
34. 34 CONFIDENTIAL - © 2022 CoDMON Inc. 34 短い間隔の処理を滞りなく実行可能であること • 1分間隔で実行される処理が複数存在。これらの処 理を滞りなく実行する必要がある • 短い間隔の処理は本来バッチではなくキューワー カーのような構成で動かすべきだが、様々な事情が ありバッチアーキテクチャからの脱却は難しい • EventBridge Scheduler → ECS Task（on Fargate）という構成だと、タスク起動に1分以上 掛かってしまうことが分かったので、採択不可
35. 35 CONFIDENTIAL - © 2022 CoDMON Inc. 35 アーキテクチャ候補 概要 デプロイ時の中断回避 短間隔での実行 1 EventBridge Scheduler → ECS Task（on EC2）起 動 デプロイ = ECSタスク定義を登録するだけ なので、 実行中の処理には影響を及ぼさない データプレーンとしてEC2を用いる場合、コ ンテナイメージキャッシュを利用できるた め、短い間隔でタスクを起動可能 2 コンテナ起動時に カスタムスクリプ トを実行して、デ プロイ時の処理中 断を回避 すべての処理が完了した後、タスクの入れ替 わりが発生するので、実行中処理のデプロイ 時の中断を回避できる cron経由で処理が実行されるので、起動時の オーバーヘッドはない 3 コードをEFSに外出 しすることで、 ECS Taskを入れ替 えずにデプロイ 処理が動くECSタスクに対してデプロイコマ ンドを実行する必要がないので可能 cron経由で処理が実行されるので、起動時の オーバーヘッドはない
36. 36 CONFIDENTIAL - © 2022 CoDMON Inc. 36 アーキテクチャ候補 構成案1 • EventBridge Scheduler → RunTask API実行 → ECS Task起 動 という流れ • ECS Taskのデータプレーンとして EC2を用いることで、コンテナイ メージキャッシュを利用し、起動 時間を高速化する
37. 37 CONFIDENTIAL - © 2022 CoDMON Inc. 37 アーキテクチャ候補 構成案2 コンテナイメージのEntrypointにカスタムスクリプ トを指定し、以下を実行 • ECS Task起動時に、自身のタスクIDを記した実行 キーをDynamoDBに保管 & 一定間隔で監視 • DynamoDBに複数の実行キーが存在する場合は、デプ ロイ期間中と見做し、cronプロセスを停止 • 旧タスクで実行中のバッチ処理が全て完了した場合は DynamoDB実行キーを更新。新タスクはそれを見て、 コンテナヘルスチェックを通過させ、デプロイを完了 させる。 • 一定期間内で、旧タスク側で実行中の処理が終了しな い場合、サーキットブレーカーによってデプロイを ロールバックする
38. 38 CONFIDENTIAL - © 2022 CoDMON Inc. 38 アーキテクチャ候補 構成案3
39. 39 CONFIDENTIAL - © 2022 CoDMON Inc. 39 アーキテクチャ選定 • 「単純で理解しやすい構成か否か」という観点を最優先事項として、アーキテ クチャ選定を実施 ◦ コンテナ化の主目的は、技術スタックとインフラ構成の標準化により開発 者の認知負荷を減らすこと ◦ リアーキテクチャリングによって複雑な構成になってしまうと、逆効果を 招いてしまう
40. 40 CONFIDENTIAL - © 2022 CoDMON Inc. 40 「単純で理解しやすい構成」の意義 ソフトウェアを単純にすることは、信頼性を持たせるための前提条件だということです。 SREサイトリライアビリティエンジニアリング 9章「単純さ」 システムの設計をできるだけ単純に保つことは、システムの信頼性とセキュリティを両方とも 評価できる能力を改善するための最も優れた方法の 1つです。 最も重要なシステムの動作に異常が見られる場合には、システムの理解しやすさが、短時間 のインシデントで済むか長期化するディザスタとなるかの明暗を分ける可能性があります。 セキュアで信頼性のあるシステム構築 6章「理解しやすさに配慮した設計」
41. 41 CONFIDENTIAL - © 2022 CoDMON Inc. 41 単純で理解しやすい構成とは • 動作を推論することが容易であるシステム ◦ システム構成を抽象化して捉えやすい ◦ 複雑さが管理されている ◦ 明確で制約された目的があるコンポーネントが組み合わさって、システ ムが構築されている
42. 42 CONFIDENTIAL - © 2022 CoDMON Inc. 42 単純で理解しやすい構成とは • 動作を推論することが容易であるシステム ◦ システム構成を抽象化して捉えやすい ◦ 複雑さが管理されている ◦ 明確で制約された目的があるコンポーネントが組み合わさって、システ ムが構築されている AWSマネージドサービスを活用して構築されて おり、独自の作り込みが最小限である構成
43. 43 CONFIDENTIAL - © 2022 CoDMON Inc. 43 単純で理解しやすい構成とは • 独自の作り込みが多い ◦ 作った人しか仕様が分からないことが、属人化やブラックボックス化を 誘発する ◦ 作り込んだ部分の信頼性を保証する必要があり、その部分でも複雑化 • 独自の作り込みが少ない ◦ マネージドサービスの仕様を知っていれば、作った人以外でも動作を推 論可能 ◦ コンポーネント箇所の信頼性はマネージドサービス側で担保できる
44. 44 CONFIDENTIAL - © 2022 CoDMON Inc. 44 アーキテクチャ選定 概要 デプロイ時の中断回避 短間隔での実行 1 EventBridge Scheduler → ECS Task（on EC2）起 動 デプロイ = ECSタスク定義を登録するだけ なので、 実行中の処理には影響を及ぼさない データプレーンとしてEC2を用いる場合、コ ンテナイメージキャッシュを利用できるた め、短い間隔でタスクを起動可能 2 コンテナ起動時に カスタムスクリプ トを実行して、デ プロイ時のバッチ 処理停止を回避 すべての処理が完了した後、タスクの入れ替 わりが発生するので、実行中処理のデプロイ 時の中断を回避できる cron経由で処理が実行されるので、起動時の オーバーヘッドはない 3 コードをEFSに外出 しすることで、 ECS Taskを入れ替 えずにデプロイ 処理が動くECSタスクに対してデプロイコマ ンドを実行する必要がないので可能 cron経由で処理が実行されるので、起動時の オーバーヘッドはない AWSマネージドサービスや APIの組み 合わせで構築可能 独自のスクリプトやロジック・運用フ ローを構築する必要がある
45. 45 CONFIDENTIAL - © 2022 CoDMON Inc. 45 アーキテクチャ選定 概要 デプロイ時の中断回避 短間隔での実行 1 EventBridge Scheduler → ECS Task（on EC2）起 動 デプロイ = ECSタスク定義を登録するだけ なので、 実行中の処理には影響を及ぼさない データプレーンとしてEC2を用いる場合、コ ンテナイメージキャッシュを利用できるた め、短い間隔でタスクを起動可能 2 コンテナ起動時に カスタムスクリプ トを実行して、デ プロイ時のバッチ 処理停止を回避 すべての処理が完了した後、タスクの入れ替 わりが発生するので、実行中処理のデプロイ 時の中断を回避できる cron経由で処理が実行されるので、起動時の オーバーヘッドはない 3 コードをEFSに外出 しすることで、 ECS Taskを入れ替 えずにデプロイ 処理が動くECSタスクに対してデプロイコマ ンドを実行する必要がないので可能 cron経由で処理が実行されるので、起動時の オーバーヘッドはない AWSマネージドサービスや APIの組み 合わせで構築可能 独自のスクリプトやロジック・運用フ ローを構築する必要がある 採用！！
46. 46 CONFIDENTIAL - © 2022 CoDMON Inc. 46 バッチサーバーをコンテナ化する際のその他Tips 1. Step Functionsの活用 2. ECSタスクの起動時間について 3. データプレーンの使い分け 4. 大量のECSタスクを起動する際の注意事項
47. 47 CONFIDENTIAL - © 2022 CoDMON Inc. 47 1：StepFunctionsの活用 1. 多重起動防止 EventBridgeの実行保証は「少なくとも1回（at-least-once）」 のため、同タイミングで複数起動する可能性がある 2. 失敗時のエラーハンドリング ECS Task起動時の特定のエラーのみ捕捉するなど、細やかなハン ドリングが可能 例) ECS.AmazonECSException / ECS.ServerException 例外を 捕捉することで、ECS起因でのエラー検知 & ハンドリングが可能 EventBridge Scheduler <> ECSタスク の間にStepFunctionsを挟む。 StepFunctionsでは以下を実施している。
48. 48 CONFIDENTIAL - © 2022 CoDMON Inc. 48 2：ECSタスクの起動時間について データプレーン(EC2 / Fargate)の他に、ネットワークモードやサイドカーコ ンテナとの依存関係の有無によって起動時間が変動する。懸念事項とのトレー ドオフで判断する。 ネットワーク モード 起動 速度 備考 bridge 速い タスク単位でSecurityGroup をアタッチできないため、 セキュリティ上の懸念あり awsvpc 遅い タスク起動時にENIをプロビ ジョニング & アタッチする 分のオーバーヘッド(数秒)が 発生する サイドカーコンテ ナとの依存関係 起動速 度 備考 なし 速い サイドカーコンテナのヘルス チェック通過後に本体を起動 しないと、挙動影響が生じる 懸念あり(例：FireLens) あり 遅い サイドカーコンテナのヘルス チェック通過を待つ分、起動 のオーバーヘッドが発生する
49. 49 CONFIDENTIAL - © 2022 CoDMON Inc. 49 2：ECSタスクの起動時間について データプレーン(EC2 / Fargate)の他に、ネットワークモードやサイドカーコ ンテナとの依存関係の有無によって起動時間が変動する。懸念事項とのトレー ドオフで判断する。 ネットワーク モード 起動 速度 備考 bridge 速い タスク単位でSecurityGroup をアタッチできないため、 セキュリティ上の懸念あり awsvpc 遅い タスク起動時にENIをプロビ ジョニング & アタッチする 分のオーバーヘッド(数秒)が 発生する サイドカーコンテ ナとの依存関係 起動速 度 備考 なし 速い サイドカーコンテナのヘルス チェック通過後に本体を起動 しないと、挙動影響が生じる 懸念あり(例：FireLens) あり 遅い サイドカーコンテナのヘルス チェック通過を待つ分、起動 のオーバーヘッドが発生する 起動時間計測 & 開発チームと相談の結果、 多少の起動時間オーバーヘッドは許容できることが分かったので、 以下を採択
50. 50 CONFIDENTIAL - © 2022 CoDMON Inc. 50 3：データプレーンの使い分け バッチ処理毎の実行間隔に応じて、EC2 / Fargate の最適な方で動かしている。 処理タイプ データプレーン 理由 実行間隔の短い処理 EC2 コンテナイメージキャッシュを利用し、タスクの高速起 動が可能。 タスク起動数によらず料金が一定。 実行間隔の長い処理 Fargate 高速起動が不要。 タスク起動時間分の課金のため、起動回数が少ない場合 に有利。 起動タスク毎に個別のvCPU/Memoryリソースを確保で きたり、ホストマシンの管理が不要など、他にもメリッ トがある。
51. 51 CONFIDENTIAL - © 2022 CoDMON Inc. 51 3：データプレーンの使い分け バッチ処理毎の実行間隔に応じて、EC2 / Fargate の適した方で動かしている。 処理タイプ データプレーン 理由 実行間隔の短い処理 EC2 コンテナイメージキャッシュを利用し、タスクの高速起 動が可能。 タスク起動数によらず料金が一定。 実行間隔の長い処理 Fargate 高速起動が不要。 タスク起動時間分の課金のため、起動回数が少ない場合 に有利。 起動タスク毎に個別のvCPU/Memoryリソースを確保で きたり、ホストマシンの管理が不要など、他にもメリッ トがある。 ただし、ECSマネージドインスタン スの登場により、今後は選定方針が 変わるかも
52. 52 CONFIDENTIAL - © 2022 CoDMON Inc. 52 4：大量のECSタスクを起動する際の注意事項 種別 概要 詳細 回避策 可用性 EC2コンテナイン スタンスで稼働可 能なタスク上限 [awsvpcネットワークモードのみ] 1つのEC2インスタンスにアタッチでき るENI数には限りがあるため、稼働可能 なECSタスク数にも制限あり 対象のEC2コンテナインスタンスに ついて、awsvpcTrunkingアカウン ト設定を有効する（起動可能なECS タスク数を増やすことが可能） 可用性 各種AWSリソー スのService Quotas StepFunctions：StartExecution / StateTransition ECS：RunTask API Service Quotasの緩和申請。できな い場合は実行タイミングをランダム に分散させるなど。 料金 AWS Config 料金 [awsvpcネットワークモードのみ] ECSタスク起動時にENIが作成されるた びAWS Config側に記録され、レコー ディングログ料金が増大する AWS Configの記録頻度を「日次記 録」で設定することで回避可能 料金 StepFunctions料 金 標準ワークフローの場合、状態遷移 1,000 回ごとに、USD 0.025 の料金が 発生。油断していると料金が増大する ワークフローの中で5分以内に完了 する & 冪等性を担保できる箇所は Expressワークフローに置換する / 無駄な状態遷移を削減する 等
53. 53 CONFIDENTIAL - © 2022 CoDMON Inc. 53 リアーキテクチャリング後の構成
54. 54 CONFIDENTIAL - © 2022 CoDMON Inc. 54 リアーキテクチャリング後の構成 EventBridge Scheduler で cron定義
55. 55 CONFIDENTIAL - © 2022 CoDMON Inc. 55 リアーキテクチャリング後の構成 EventBridge Scheduler で cron定義 StepFunctionsで 以下を実施 ・多重起動防止 ・ECS Task実行 ・失敗時のエラー ハンドリング
56. 56 CONFIDENTIAL - © 2022 CoDMON Inc. 56 リアーキテクチャリング後の構成 EventBridge Scheduler で cron定義 StepFunctionsで 以下を実施 ・多重起動防止 ・ECS Task実行 ・失敗時のエラー ハンドリング バッチ処理実行間 隔に応じて 適切なデータプ レーンを選択 実行間隔が短い処 理は、EC2データ プレーンを利用し タスク起動時間を 高速化
57. 57 目次 1. コドモンSREチームの取り組み 2. リアーキテクチャリングはじめの一歩 3. システムの信頼性を向上するための設計・実装のポイント 4. 安全なローンチのために取り組んだこと 5. まとめ
58. 58 CONFIDENTIAL - © 2022 CoDMON Inc. 58 安全なローンチのために取り組んだこと • 小さく早く失敗する • 失敗から学んで修正する "Think big; act small; fail fast; learn rapidly." Lean Software Development: An Agile Toolkit
59. 59 CONFIDENTIAL - © 2022 CoDMON Inc. 59 安全なローンチのために取り組んだこと • 小さく早く失敗する • 失敗から学んで修正する "Think big; act small; fail fast; learn rapidly." Lean Software Development: An Agile Toolkit 1. CICD・監視機構（アラート / ログ / メトリクスダッシュボード）は早期に 作成し、試験的に運用する 2. 負荷試験によって高負荷時の挙動を理解する 3. 影響の少ない処理から徐々に移行する
60. 60 CONFIDENTIAL - © 2022 CoDMON Inc. 60 安全なローンチのために取り組んだこと • 小さく早く失敗する • 失敗から学んで修正する "Think big; act small; fail fast; learn rapidly." Lean Software Development: An Agile Toolkit 1. CICD・監視機構（アラート / ログ / メトリクスダッシュボード）は早期に 作成し、試験的に運用する 2. 負荷試験によって高負荷時の挙動を理解する 3. 影響の少ない処理から徐々に移行する
61. 61 CONFIDENTIAL - © 2022 CoDMON Inc. 61 CICD・監視機構は早期に作成し、試験的に運用する • CICD ◦ 定期リリースパイプラインへの追加 ◦ 手動デプロイワークフローの実装 ◦ ロールバックワークフローの実装 • 監視機構 ◦ ログ基盤 ◦ アラート ◦ メトリクスダッシュボード ◦ APM
62. 62 CONFIDENTIAL - © 2022 CoDMON Inc. 62 CICD・監視機構は早期に作成し、試験的に運用する • 小さく早く失敗する ◦ いずれもローンチ以降では必須となるので、実装上の制約や問題が発見 された際に、設計や実装方針の修正を早期に実施することができる • 失敗から学んで修正する ◦ 早期に監視機構を構築しておくことで、動作確認や負荷試験の結果から 修正対応を実施しやすくなる ◦ CICD・監視機構は開発者体験に直結する。本運用に入る前に改善サイク ルを回すことで、CICD・監視機構を育てていく
63. 63 CONFIDENTIAL - © 2022 CoDMON Inc. 63 安全なローンチのために取り組んだこと • 小さく早く失敗する • 失敗から学んで修正する "Think big; act small; fail fast; learn rapidly." Lean Software Development: An Agile Toolkit 1. CICD・監視機構（アラート / ログ / メトリクスダッシュボード）は早期に 作成し、試験的に運用する 2. 負荷試験によって高負荷時の挙動を理解する 3. 影響の少ない処理から徐々に移行する
64. 64 CONFIDENTIAL - © 2022 CoDMON Inc. 64 負荷試験によって高負荷時の挙動を理解する 高負荷の下でのサービスの挙動を理解することは、カスケード 障害を避けるための最も重要な最初の一歩でしょう。 22章「カスケード障害への対応」 信頼性という面からもキャパシティプランニングという面からも 負荷テストには計り知れない価値があり、ほとんどのローンチ に必須なのです。 27章「大規模なプロダクトのローンチにおける信頼性」 SREサイトリライアビリティエンジニアリング • カスケード障害以外にも、高負荷時は予期せぬ挙動が発生しやすい。 • 高負荷時の挙動やエラーを早期に把握しておく（意図的な失敗を早期に起こ す）ことで、本運用後の障害発生を緩和できる。 ※ カスケード障害： システムの一部で発生した障害が、他の部 分へ連鎖的に波及し、やがてシステム全体 に広がる現象
65. 65 CONFIDENTIAL - © 2022 CoDMON Inc. 65 負荷試験によって高負荷時の挙動を理解する • データプレーン（EC2 / Fargate）毎に実施 • バッチ処理用の負荷試験基盤やテスト基盤はなかったので、意図的に負荷を かけるバッチ処理を作成して検証 ◦ 小さく手軽に始めて、計測結果を得ることが重要。 観点 負荷試験手法 メモリ負荷 アプリケーションの上限値(php.ini の memory_limit)近くまでメモリを使った際に OutOfMemoryErrorが発生しないことを確認 CPU負荷 一定時間内で、負荷のかかる処理(素数探索・ハッシュ計算 等)を実施し、CPU過使 用時の挙動を検証。EC2データプレーン時はタスク起動数による性能変動も検証 タスク起動数 短時間で大量のタスクを起動させた際の挙動・EC2コンテナインスタンスで稼働可 能なタスク数を超えた際の挙動を検証
66. 66 CONFIDENTIAL - © 2022 CoDMON Inc. 66 安全なローンチのために取り組んだこと • 小さく早く失敗する • 失敗から学んで修正する "Think big; act small; fail fast; learn rapidly." Lean Software Development: An Agile Toolkit 1. CICD・監視機構（アラート / ログ / メトリクスダッシュボード）は早期に 作成し、試験的に運用する 2. 負荷試験によって高負荷時の挙動を理解する 3. 影響の少ない処理から徐々に移行する
67. 67 CONFIDENTIAL - © 2022 CoDMON Inc. 67 影響の少ない処理から徐々に移行する • 各バッチ処理は個々で独立して動いているので、一気に移行するのではなく 処理単位で移行可能 • 処理毎に影響度（移行のしやすさ）を可視化した上で、失敗時の影響が少な い処理から移行していくことで、大きな失敗を避けつつ移行時のFBを得るこ とができる
68. 68 CONFIDENTIAL - © 2022 CoDMON Inc. 68 処理毎の影響度を可視化する方法 • 担当処理毎に、失敗した際の顧客影響(なし・あり・重大) / 失敗時にリトライ可能か否か 等の観点 を整理（担当チームへのヒアリングより情報収集） • 上記を元に処理毎の影響度を可視化する
69. 69 目次 1. コドモンSREチームの取り組み 2. リアーキテクチャリングはじめの一歩 3. システムの信頼性を向上するための設計・実装のポイント 4. 安全なローンチのために取り組んだこと 5. まとめ
70. 70 CONFIDENTIAL - © 2022 CoDMON Inc. 70 リアーキテクチャリングの実施結果 [実施前] • 構成管理はSREに依存。 一方、構成に詳しいエンジニアは 既に離任していたため、ブラック ボックス化していた • 開発者 / SRE 双方にとって認知負 荷が高い • 可観測性が低く、時より原因不明 のエラーが発生する [実施後] • 他サービスと同様に標準化された実行基盤 （ECSによるコンテナ環境）で稼働。 • これによって、開発者 / SRE 双方の認知負 荷を改善し、ブラックボックス状態を解 消。 • SREに依存せず、開発チーム主体でのミド ルウェア導入もできるようになった • 監視基盤の導入により可観測性が向上し、 異常時のアクション等が容易になった
71. 71 CONFIDENTIAL - © 2022 CoDMON Inc. 71 本番環境ローンチの実施結果 • 現在も本番環境に移行中だが、今のところ大きな問題は発生していない • 本番相当環境での負荷試験にていくつかの不具合を検知し、ローンチ前に修 正することができた ◦ 例）APMのためにECSコンテナインスタンスのPrivateIPを取得する際。EC2メタデータサー ビスへの問い合わせだと時よりエラーが発生することを発見し、コンテナメタデータファイル 経由で取得する方式に変更した ◦ 例）FireLens(FluentBit)サイドカーコンテナを用いたログルーティング実施時、FireLensが HEALTYになってから本体のコンテナを起動させないと、時よりログの欠損 および タスクの 異常停止を招くことに気づいた
72. 72 CONFIDENTIAL - © 2022 CoDMON Inc. 72 リアーキテクチャリングの手法を抽象化 「影響範囲が広く重要度が高い」一方で「ブラックボックス化しつつある」イン フラ基盤を「SREが主導して」リアーキテクチャリングする手法 1. 複数の情報源を通じた構成把握・要件分析によって、リアーキテクチャリン グの方針を立案。またヒアリングを通じて開発チームとの関係性を構築 2. 単純で理解しやすい構成に重きをおいたアーキテクチャ設計・選定 3. 小さく早く失敗することによる安全なローンチの実施