レガシー共有バッチ基盤への挑戦 - SREドリブンなリアーキテクチャリングの取り組み

by Konishi tatsuhiro

Slide 1

Slide 1 text

レガシー共有バッチ基盤への挑戦 SREドリブンなリアーキテクチャリングの取り組み 2026年1月31日株式会社コドモン小西達大 SRE Kaigi 2026

Slide 2

Slide 2 text

2 経歴前職でアプリケーションエンジニアとして従事後、株式会社コドモンのSREチームにジョイン。大阪在住。自己紹介小西達大こにしたつひろ

Slide 3

Slide 3 text

3 パパママと、子どもとの時間に 1秒でも多くの笑顔と愛情をすべての先生に子どもと向き合う時間と心のゆとりを「保育・子育て」と社会をつなげる保護者の子育てへの伴走保育・教育者の環境改善子育ての社会インフラ作り子どもを取り巻く環境をテクノロジーの力でよりよいものにミッション私たちの使命

Slide 4

Slide 4 text

すべての先生に子どもと向き合う時間と心のゆとりをこんなプロダクトを開発していますメインプロダクトは、こども施設職員の業務を支援するWebアプリケーション。保護者と施設のやり取りを支えるモバイルアプリケーションや、施設職員向けモバイル版アプリケーション、外部サービスと連携するAPIなども開発しています。 4

Slide 5

Slide 5 text

Slide 6

Slide 6 text

6 目次 1. コドモンSREチームの取り組み 2. リアーキテクチャリングはじめの一歩 3. システムの信頼性を向上するための設計・実装のポイント 4. 安全なローンチのために取り組んだこと 5. まとめ

Slide 7

Slide 7 text

7 目次 1. コドモンSREチームの取り組み 2. リアーキテクチャリングはじめの一歩 3. システムの信頼性を向上するための設計・実装のポイント 4. 安全なローンチのために取り組んだこと 5. まとめ

Slide 8

Slide 8 text

UI/UXデザイナープロダクトセキュリティエンジニア・QA プロダクトマネージャー新規事業チーム 1チームは関連する複数の機能を担当技術戦略計9名計48名計9名計5名計8名コドモン開発チーム編成 8 SRE 計5名 … … 他数チーム組織横断チ｜ム … メンバー … マネージャー zzz機能チーム yyy機能チーム xxx機能チーム … … …

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

12 CONFIDENTIAL - © 2022 CoDMON Inc. 12 バッチサーバーのコンテナ化に取りかかろうとするが... OS（Amazon Linux 2）のサポート終了案内を契機に、バッチサーバーについてもコンテナ化に取り掛かろうとするが... ● ブラックボックス化しつつあり、構成が不明瞭 ○ 構成管理はSREに依存。一方、構成に詳しいエンジニアは既に離任 ○ 可観測性が低く、時より原因不明のエラーが発生する ● 改修に伴う影響範囲・影響度は大きい ○ 複数の開発チームが、管轄の処理を動かしており、サービス的に重要な処理も動いている

Slide 13

Slide 13 text

13 CONFIDENTIAL - © 2022 CoDMON Inc. 13 バッチサーバーのコンテナ化に取りかかろうとするが... OS（Amazon Linux 2）のサポート終了案内を契機に、バッチサーバーについてもコンテナ化に取り掛かろうとするが... ● ブラックボックス化しつつあり、構成が不明瞭 ○ 構成管理はSREに依存。一方、構成に詳しいエンジニアは既に離任 ○ 可観測性が低く、時より原因不明のエラーが発生する ● 改修に伴う影響範囲・影響度は大きい ○ 複数の開発チームが、管轄の処理を動かしており、サービス的に重要な処理も動いている一筋縄では行かなそう...

Slide 14

Slide 14 text

Slide 15

Slide 15 text

15 目次 1. コドモンSREチームの取り組み 2. リアーキテクチャリングはじめの一歩 3. システムの信頼性を向上するための設計・実装のポイント 4. 安全なローンチのために取り組んだこと 5. まとめ

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Slide 20

Slide 20 text

20 CONFIDENTIAL - © 2022 CoDMON Inc. 20 1：何はともあれ情報収集 ● インフラ設計書や構成図・IaCのコードはもちろん有用な情報 ● 一方、更新されていない / そもそも存在しないというケースもあるので、それだけに頼らず実環境・実運用からも情報収集する。 ● たとえば、以下の情報源から有用な情報を得ることができる ○ プロダクション環境のリバースエンジニアリング ○ 過去のエラー対応 ○ アプリケーションのコード

Slide 21

Slide 21 text

21 CONFIDENTIAL - © 2022 CoDMON Inc. 21 プロダクション環境のリバースエンジニアリング ● 実際に動いている環境から情報収集する ○ 動いているプロセス / 動いているcron / インストールされたパッケージ / ファイルパーミッション / プログラミング言語設定情報 … ○ 例) コード管理されていると思っていたcrontabファイルが実際には使われておらず、インスタンス内で直接crontabを更新する運用だった

Slide 22

Slide 22 text

Slide 23

Slide 23 text

23 CONFIDENTIAL - © 2022 CoDMON Inc. 23 アプリケーションのコード ● コードの詳細まで完璧に理解する必要はないが、AIを用いるなどしてざっくりと流れを掴む ● 冒頭 / 末尾で実施されている共通処理や、外部リソースとの通信部分に着目することで、アプリケーション <> インフラ間の接点の理解に繋がる ○ 例) 処理の冒頭で空ファイルを作成。以降の処理ではファイルの存在判定を行うことにより、多重起動を防止する構成となっていた

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Slide 28

Slide 28 text

28 CONFIDENTIAL - © 2022 CoDMON Inc. 28 3：各バッチ処理の担当チームにヒアリング ● ヒアリングを行う目的 ○ 各処理毎の詳細な情報収集 ○ 各担当チームとの関係性作り ● SREチーム側である程度の情報収集を行ってからヒアリングを実施した理由 ○ 事前に情報収集した情報を元に「質問」だけではなく「議論」をすることで、得られる情報の精度を高めることができるため

Slide 29

Slide 29 text

Slide 30

Slide 30 text

30 目次 1. コドモンSREチームの取り組み 2. リアーキテクチャリングはじめの一歩 3. システムの信頼性を向上するための設計・実装のポイント 4. 安全なローンチのために取り組んだこと 5. まとめ

Slide 31

Slide 31 text

Slide 32

Slide 32 text

Slide 33

Slide 33 text

Slide 34

Slide 34 text

34 CONFIDENTIAL - © 2022 CoDMON Inc. 34 短い間隔の処理を滞りなく実行可能であること ● 1分間隔で実行される処理が複数存在。これらの処理を滞りなく実行する必要がある ● 短い間隔の処理は本来バッチではなくキューワーカーのような構成で動かすべきだが、様々な事情がありバッチアーキテクチャからの脱却は難しい ● EventBridge Scheduler → ECS Task（on Fargate）という構成だと、タスク起動に1分以上掛かってしまうことが分かったので、採択不可

Slide 35

Slide 35 text

35 CONFIDENTIAL - © 2022 CoDMON Inc. 35 アーキテクチャ候補概要デプロイ時の中断回避短間隔での実行 1 EventBridge Scheduler → ECS Task（on EC2）起動デプロイ = ECSタスク定義を登録するだけなので、実行中の処理には影響を及ぼさないデータプレーンとしてEC2を用いる場合、コンテナイメージキャッシュを利用できるため、短い間隔でタスクを起動可能 2 コンテナ起動時にカスタムスクリプトを実行して、デプロイ時の処理中断を回避すべての処理が完了した後、タスクの入れ替わりが発生するので、実行中処理のデプロイ時の中断を回避できる cron経由で処理が実行されるので、起動時のオーバーヘッドはない 3 コードをEFSに外出しすることで、 ECS Taskを入れ替えずにデプロイ処理が動くECSタスクに対してデプロイコマンドを実行する必要がないので可能 cron経由で処理が実行されるので、起動時のオーバーヘッドはない

Slide 36

Slide 36 text

Slide 37

Slide 37 text

37 CONFIDENTIAL - © 2022 CoDMON Inc. 37 アーキテクチャ候補構成案2 コンテナイメージのEntrypointにカスタムスクリプトを指定し、以下を実行 ● ECS Task起動時に、自身のタスクIDを記した実行キーをDynamoDBに保管 & 一定間隔で監視 ● DynamoDBに複数の実行キーが存在する場合は、デプロイ期間中と見做し、cronプロセスを停止 ● 旧タスクで実行中のバッチ処理が全て完了した場合は DynamoDB実行キーを更新。新タスクはそれを見て、コンテナヘルスチェックを通過させ、デプロイを完了させる。 ● 一定期間内で、旧タスク側で実行中の処理が終了しない場合、サーキットブレーカーによってデプロイをロールバックする

Slide 38

Slide 38 text

Slide 39

Slide 39 text

Slide 40

Slide 40 text

40 CONFIDENTIAL - © 2022 CoDMON Inc. 40 「単純で理解しやすい構成」の意義ソフトウェアを単純にすることは、信頼性を持たせるための前提条件だということです。 SREサイトリライアビリティエンジニアリング 9章「単純さ」システムの設計をできるだけ単純に保つことは、システムの信頼性とセキュリティを両方とも評価できる能力を改善するための最も優れた方法の 1つです。最も重要なシステムの動作に異常が見られる場合には、システムの理解しやすさが、短時間のインシデントで済むか長期化するディザスタとなるかの明暗を分ける可能性があります。セキュアで信頼性のあるシステム構築 6章「理解しやすさに配慮した設計」

Slide 41

Slide 41 text

Slide 42

Slide 42 text

Slide 43

Slide 43 text

43 CONFIDENTIAL - © 2022 CoDMON Inc. 43 単純で理解しやすい構成とは ● 独自の作り込みが多い ○ 作った人しか仕様が分からないことが、属人化やブラックボックス化を誘発する ○ 作り込んだ部分の信頼性を保証する必要があり、その部分でも複雑化 ● 独自の作り込みが少ない ○ マネージドサービスの仕様を知っていれば、作った人以外でも動作を推論可能 ○ コンポーネント箇所の信頼性はマネージドサービス側で担保できる

Slide 44

Slide 44 text

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の組み合わせで構築可能独自のスクリプトやロジック・運用フローを構築する必要がある

Slide 45

Slide 45 text

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の組み合わせで構築可能独自のスクリプトやロジック・運用フローを構築する必要がある採用！！

Slide 46

Slide 46 text

Slide 47

Slide 47 text

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では以下を実施している。

Slide 48

Slide 48 text

48 CONFIDENTIAL - © 2022 CoDMON Inc. 48 2：ECSタスクの起動時間についてデータプレーン(EC2 / Fargate)の他に、ネットワークモードやサイドカーコンテナとの依存関係の有無によって起動時間が変動する。懸念事項とのトレードオフで判断する。ネットワークモード起動速度備考 bridge 速いタスク単位でSecurityGroup をアタッチできないため、セキュリティ上の懸念あり awsvpc 遅いタスク起動時にENIをプロビジョニング & アタッチする分のオーバーヘッド(数秒)が発生するサイドカーコンテナとの依存関係起動速度備考なし速いサイドカーコンテナのヘルスチェック通過後に本体を起動しないと、挙動影響が生じる懸念あり(例：FireLens) あり遅いサイドカーコンテナのヘルスチェック通過を待つ分、起動のオーバーヘッドが発生する

Slide 49

Slide 49 text

49 CONFIDENTIAL - © 2022 CoDMON Inc. 49 2：ECSタスクの起動時間についてデータプレーン(EC2 / Fargate)の他に、ネットワークモードやサイドカーコンテナとの依存関係の有無によって起動時間が変動する。懸念事項とのトレードオフで判断する。ネットワークモード起動速度備考 bridge 速いタスク単位でSecurityGroup をアタッチできないため、セキュリティ上の懸念あり awsvpc 遅いタスク起動時にENIをプロビジョニング & アタッチする分のオーバーヘッド(数秒)が発生するサイドカーコンテナとの依存関係起動速度備考なし速いサイドカーコンテナのヘルスチェック通過後に本体を起動しないと、挙動影響が生じる懸念あり(例：FireLens) あり遅いサイドカーコンテナのヘルスチェック通過を待つ分、起動のオーバーヘッドが発生する起動時間計測 & 開発チームと相談の結果、多少の起動時間オーバーヘッドは許容できることが分かったので、以下を採択

Slide 50

Slide 50 text

50 CONFIDENTIAL - © 2022 CoDMON Inc. 50 3：データプレーンの使い分けバッチ処理毎の実行間隔に応じて、EC2 / Fargate の最適な方で動かしている。処理タイプデータプレーン理由実行間隔の短い処理 EC2 コンテナイメージキャッシュを利用し、タスクの高速起動が可能。タスク起動数によらず料金が一定。実行間隔の長い処理 Fargate 高速起動が不要。タスク起動時間分の課金のため、起動回数が少ない場合に有利。起動タスク毎に個別のvCPU/Memoryリソースを確保できたり、ホストマシンの管理が不要など、他にもメリットがある。

Slide 51

Slide 51 text

51 CONFIDENTIAL - © 2022 CoDMON Inc. 51 3：データプレーンの使い分けバッチ処理毎の実行間隔に応じて、EC2 / Fargate の適した方で動かしている。処理タイプデータプレーン理由実行間隔の短い処理 EC2 コンテナイメージキャッシュを利用し、タスクの高速起動が可能。タスク起動数によらず料金が一定。実行間隔の長い処理 Fargate 高速起動が不要。タスク起動時間分の課金のため、起動回数が少ない場合に有利。起動タスク毎に個別のvCPU/Memoryリソースを確保できたり、ホストマシンの管理が不要など、他にもメリットがある。ただし、ECSマネージドインスタンスの登場により、今後は選定方針が変わるかも

Slide 52

Slide 52 text

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ワークフローに置換する / 無駄な状態遷移を削減する等

Slide 53

Slide 53 text

Slide 54

Slide 54 text

Slide 55

Slide 55 text

Slide 56

Slide 56 text

Slide 57

Slide 57 text

57 目次 1. コドモンSREチームの取り組み 2. リアーキテクチャリングはじめの一歩 3. システムの信頼性を向上するための設計・実装のポイント 4. 安全なローンチのために取り組んだこと 5. まとめ

Slide 58

Slide 58 text

Slide 59

Slide 59 text

59 CONFIDENTIAL - © 2022 CoDMON Inc. 59 安全なローンチのために取り組んだこと ● 小さく早く失敗する ● 失敗から学んで修正する "Think big; act small; fail fast; learn rapidly." Lean Software Development: An Agile Toolkit 1. CICD・監視機構（アラート / ログ / メトリクスダッシュボード）は早期に作成し、試験的に運用する 2. 負荷試験によって高負荷時の挙動を理解する 3. 影響の少ない処理から徐々に移行する

Slide 60

Slide 60 text

60 CONFIDENTIAL - © 2022 CoDMON Inc. 60 安全なローンチのために取り組んだこと ● 小さく早く失敗する ● 失敗から学んで修正する "Think big; act small; fail fast; learn rapidly." Lean Software Development: An Agile Toolkit 1. CICD・監視機構（アラート / ログ / メトリクスダッシュボード）は早期に作成し、試験的に運用する 2. 負荷試験によって高負荷時の挙動を理解する 3. 影響の少ない処理から徐々に移行する

Slide 61

Slide 61 text

Slide 62

Slide 62 text

62 CONFIDENTIAL - © 2022 CoDMON Inc. 62 CICD・監視機構は早期に作成し、試験的に運用する ● 小さく早く失敗する ○ いずれもローンチ以降では必須となるので、実装上の制約や問題が発見された際に、設計や実装方針の修正を早期に実施することができる ● 失敗から学んで修正する ○ 早期に監視機構を構築しておくことで、動作確認や負荷試験の結果から修正対応を実施しやすくなる ○ CICD・監視機構は開発者体験に直結する。本運用に入る前に改善サイクルを回すことで、CICD・監視機構を育てていく

Slide 63

Slide 63 text

63 CONFIDENTIAL - © 2022 CoDMON Inc. 63 安全なローンチのために取り組んだこと ● 小さく早く失敗する ● 失敗から学んで修正する "Think big; act small; fail fast; learn rapidly." Lean Software Development: An Agile Toolkit 1. CICD・監視機構（アラート / ログ / メトリクスダッシュボード）は早期に作成し、試験的に運用する 2. 負荷試験によって高負荷時の挙動を理解する 3. 影響の少ない処理から徐々に移行する

Slide 64

Slide 64 text

64 CONFIDENTIAL - © 2022 CoDMON Inc. 64 負荷試験によって高負荷時の挙動を理解する高負荷の下でのサービスの挙動を理解することは、カスケード障害を避けるための最も重要な最初の一歩でしょう。 22章「カスケード障害への対応」信頼性という面からもキャパシティプランニングという面からも負荷テストには計り知れない価値があり、ほとんどのローンチに必須なのです。 27章「大規模なプロダクトのローンチにおける信頼性」 SREサイトリライアビリティエンジニアリング ● カスケード障害以外にも、高負荷時は予期せぬ挙動が発生しやすい。 ● 高負荷時の挙動やエラーを早期に把握しておく（意図的な失敗を早期に起こす）ことで、本運用後の障害発生を緩和できる。 ※ カスケード障害：システムの一部で発生した障害が、他の部分へ連鎖的に波及し、やがてシステム全体に広がる現象

Slide 65

Slide 65 text

65 CONFIDENTIAL - © 2022 CoDMON Inc. 65 負荷試験によって高負荷時の挙動を理解する ● データプレーン（EC2 / Fargate）毎に実施 ● バッチ処理用の負荷試験基盤やテスト基盤はなかったので、意図的に負荷をかけるバッチ処理を作成して検証 ○ 小さく手軽に始めて、計測結果を得ることが重要。観点負荷試験手法メモリ負荷アプリケーションの上限値(php.ini の memory_limit)近くまでメモリを使った際に OutOfMemoryErrorが発生しないことを確認 CPU負荷一定時間内で、負荷のかかる処理(素数探索・ハッシュ計算等)を実施し、CPU過使用時の挙動を検証。EC2データプレーン時はタスク起動数による性能変動も検証タスク起動数短時間で大量のタスクを起動させた際の挙動・EC2コンテナインスタンスで稼働可能なタスク数を超えた際の挙動を検証

Slide 66

Slide 66 text

66 CONFIDENTIAL - © 2022 CoDMON Inc. 66 安全なローンチのために取り組んだこと ● 小さく早く失敗する ● 失敗から学んで修正する "Think big; act small; fail fast; learn rapidly." Lean Software Development: An Agile Toolkit 1. CICD・監視機構（アラート / ログ / メトリクスダッシュボード）は早期に作成し、試験的に運用する 2. 負荷試験によって高負荷時の挙動を理解する 3. 影響の少ない処理から徐々に移行する

Slide 67

Slide 67 text

Slide 68

Slide 68 text

Slide 69

Slide 69 text

69 目次 1. コドモンSREチームの取り組み 2. リアーキテクチャリングはじめの一歩 3. システムの信頼性を向上するための設計・実装のポイント 4. 安全なローンチのために取り組んだこと 5. まとめ

Slide 70

Slide 70 text

70 CONFIDENTIAL - © 2022 CoDMON Inc. 70 リアーキテクチャリングの実施結果 [実施前] ● 構成管理はSREに依存。一方、構成に詳しいエンジニアは既に離任していたため、ブラックボックス化していた ● 開発者 / SRE 双方にとって認知負荷が高い ● 可観測性が低く、時より原因不明のエラーが発生する [実施後] ● 他サービスと同様に標準化された実行基盤（ECSによるコンテナ環境）で稼働。 ● これによって、開発者 / SRE 双方の認知負荷を改善し、ブラックボックス状態を解消。 ● SREに依存せず、開発チーム主体でのミドルウェア導入もできるようになった ● 監視基盤の導入により可観測性が向上し、異常時のアクション等が容易になった

Slide 71

Slide 71 text

71 CONFIDENTIAL - © 2022 CoDMON Inc. 71 本番環境ローンチの実施結果 ● 現在も本番環境に移行中だが、今のところ大きな問題は発生していない ● 本番相当環境での負荷試験にていくつかの不具合を検知し、ローンチ前に修正することができた ○ 例）APMのためにECSコンテナインスタンスのPrivateIPを取得する際。EC2メタデータサービスへの問い合わせだと時よりエラーが発生することを発見し、コンテナメタデータファイル経由で取得する方式に変更した ○ 例）FireLens(FluentBit)サイドカーコンテナを用いたログルーティング実施時、FireLensが HEALTYになってから本体のコンテナを起動させないと、時よりログの欠損およびタスクの異常停止を招くことに気づいた

Slide 72

Slide 72 text

72 CONFIDENTIAL - © 2022 CoDMON Inc. 72 リアーキテクチャリングの手法を抽象化「影響範囲が広く重要度が高い」一方で「ブラックボックス化しつつある」インフラ基盤を「SREが主導して」リアーキテクチャリングする手法 1. 複数の情報源を通じた構成把握・要件分析によって、リアーキテクチャリングの方針を立案。またヒアリングを通じて開発チームとの関係性を構築 2. 単純で理解しやすい構成に重きをおいたアーキテクチャ設計・選定 3. 小さく早く失敗することによる安全なローンチの実施

Slide 73

Slide 73 text

No content