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

失敗から始まるリアーキテクト: SREの実践例で見る改善の道筋

Naomichi Yamakita
December 18, 2024
97

失敗から始まるリアーキテクト: SREの実践例で見る改善の道筋

Naomichi Yamakita

December 18, 2024
Tweet

Transcript

  1. ©2024 Metaps Holdings, Inc. ⾃⼰紹介 ⼭北 尚道 株式会社メタップスホールディングス srestプロダクトオーナー 兼

    SREマネジャー Yamakita Naomichi @sre_yamakita ベトナム‧ハノイでのオフショア事業⽴ち上げからキャリアをスタートし、ア プリケーション開発からマネジメントまでを経験 2015年に当社参画。徐々にクラウドインフラにも携わり、現在は横断的なテッ クリードやSREチーフエンジニアとして従事 「AWS DevDay Tokyo」登壇、「Amazon Web Services ブログ」、 「builders.flash」寄稿 昨年よりSREのためのダッシュボード「srest」プロダクトオーナーを兼任
  2. ©2024 Metaps Holdings, Inc. ©2024 Metaps Holdings, Inc. オンコール発⽣頻度の低下 年

    オンコール発生回数 月あたりのオンコール回数 2022年 96回 8 2023年 66回 (↓31.25%) 5.5 2024年 (11月末時点) 40回 (↓39.39%) 3.6
  3. ©2024 Metaps Holdings, Inc. ©2024 Metaps Holdings, Inc. • ⼀⼈のSREエンジニアが2〜3のサービスを運⽤している

    • アラートの発⽣頻度や傾向のトレースがおざなりに ◦ 「HTTP 5XXのアラート調査どうなりました?」→ アラートが多すぎてSlackのメッセージを⾒失 う ◦ SentryやDatadogなど、アカウントを横断してアラートの傾向‧集計が⾒たい 発⽣した課題
  4. ©2024 Metaps Holdings, Inc. ©2024 Metaps Holdings, Inc. 何をしたか? •

    Terraformディレクトリ構造の再構築 • Amazon DocumentDBからAmazon OpenSearch Serviceへの移⾏ • AWS Batchの導⼊
  5. ©2024 Metaps Holdings, Inc. 従来のディレクトリ設計 • EC2やS3など、サービス単位でディレクトリを分ける • 操作ミスが発⽣しても障害範囲を最⼩限に抑えられる •

    複数⼈で作業していても、コンフリクトが発⽣しにくい • stateがディレクトリ単位の管理となるため、dataの依 存関係が分かりづらい
  6. ©2024 Metaps Holdings, Inc. ディレクトリ構造の⽐較 ディレクトリを分けない サービスごとに ディレクトリを分割 抽象化したレイヤーで ディレクトリを分割

    applyの回数 1回で済む ▲サービス単位で実行 レイヤーの粒度で実行 安全性 ▲低い (影響範囲が広域に及ぶ) 高い 比較的高い tfstateのサイズ ▲非常に大きい (applyの実行速度に影響) 小さい 比較的小さい リソース間の 依存関係 シンプル ▲複雑 比較的シンプル コンフリクト ▲発生しやすい 発生しづらい 比較的発生しづらい
  7. ©2024 Metaps Holdings, Inc. ©2024 Metaps Holdings, Inc. • srestは、EventBridgeやAPIからイベントを

    収集‧可視化する仕組みのため、スキーマ レスでデータを格納できるデータベースが 適していた • AWSのサービスではOpenSearch Service、 DocumentDBが候補に上がっていた • OpenSearch Serviceは利⽤料が⾼額になる ため、初期リリース段階ではDocumentDB を採⽤ • ...は、想定していたが、ドキュメントが数百 万を超えた辺りから、ダッシュボードでの リアルタイム集計が厳しくなった DocumentDBの採⽤理由
  8. ©2024 Metaps Holdings, Inc. ©2024 Metaps Holdings, Inc. • 料⾦の試算

    ◦ 安定稼働にはデータノードのほか、マスターノードが最低3台必要 ◦ 変数が多く、料⾦試算が難しい ▪ データノードのインスタンスサイズ、インスタンス数、ストレージサイズ ▪ マスターノード数 ▪ 利⽤者増加に伴うスケール設計 • データはExpand and Contract⽅式で移⾏ OpenSearch Service移⾏への課題
  9. ©2024 Metaps Holdings, Inc. Amazon DocumentDB Amazon OpenSearch Service Amazon

    DynamoDB 書き込み 中速 低速 高速 読み込み ▲中速 (メモリ次第) 高速 高速 複雑な検索 可能 可能 ▲やや難しい (設計次第) スケーラビリティ 中 高 (インデックスやシャードの設 計が必要) 高 (オートスケール可能) メンテナンス ウィンドウ あり あり なし 利用料 インスタンスやストレージ使用量 による (RI) インスタンスやストレージ使用量 による 安い スキーマレスデータベースの機能⽐較
  10. ©2024 Metaps Holdings, Inc. ©2024 Metaps Holdings, Inc. Lambda 15分の壁

    • srestではOpenSearchで収集したログの 集計を回していたが、Lambdaでは15分 の制限があり、バッチが終わらない状況 が発⽣ • 候補として上がったのはAWS Fargateと AWS Batch。今回はジョブキュー管理も できるBatchを採⽤
  11. ©2024 Metaps Holdings, Inc. ©2024 Metaps Holdings, Inc. • Fargate基盤

    (あるいはEC2) でSQS + Run taskを実⾏することができる ◦ ジョブを作成すると、ECSクラスターのコ ンソールでクラスターが作成されているこ とが確認できる • バッチの種別によって柔軟にコンピュー ティングリソースを設定可能 ◦ タスク定義はBatchのコンソールから登録 Fargateとの違いは?
  12. ©2024 Metaps Holdings, Inc. AWS Lambda AWS Fargate AWS Batch

    構築が容易か ◎ △ (デプロイの整備) ◯ 大規模データ処理 ▲✕ △ ◯ 実行速度 ◎ ◯ △ リトライ あり なし あり 他のサービスとの連携 ◎ △ △ 実行時間の制限 ▲最大15分 なし なし サーバーレス コンピューティング環境の⽐較