Slide 1

Slide 1 text

©2024 Metaps Holdings, Inc. # 2024.12.18 渋⾕でSRE⼤忘年会 失敗から始まるリアーキテクト: SREの実践例で⾒る改善の道筋 株式会社メタップスホールディングス プロダクトオーナー 兼 SREマネジャー ⼭北 尚道

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

©2024 Metaps Holdings, Inc. はじめに 3

Slide 4

Slide 4 text

©2024 Metaps Holdings, Inc. SREの皆様 1年間お疲れ様でした 4

Slide 5

Slide 5 text

©2024 Metaps Holdings, Inc. 今年、信頼性を向上させる施策は できましたでしょうか? 5

Slide 6

Slide 6 text

©2024 Metaps Holdings, Inc. (弊社の場合) オンコール発⽣頻度を 計測してみました 6

Slide 7

Slide 7 text

©2024 Metaps Holdings, Inc. 2022年のオンコール

Slide 8

Slide 8 text

©2024 Metaps Holdings, Inc. 2023年のオンコール

Slide 9

Slide 9 text

©2024 Metaps Holdings, Inc. 2024年のオンコール (11⽉末時点)

Slide 10

Slide 10 text

©2024 Metaps Holdings, Inc. ©2024 Metaps Holdings, Inc. オンコール発⽣頻度の低下 年 オンコール発生回数 月あたりのオンコール回数 2022年 96回 8 2023年 66回 (↓31.25%) 5.5 2024年 (11月末時点) 40回 (↓39.39%) 3.6

Slide 11

Slide 11 text

©2024 Metaps Holdings, Inc. メタップスHDにおける SREの運⽤体制 11

Slide 12

Slide 12 text

©2024 Metaps Holdings, Inc. SREはプロダクトを横断した組織

Slide 13

Slide 13 text

©2024 Metaps Holdings, Inc. SREの関⼼領域

Slide 14

Slide 14 text

©2024 Metaps Holdings, Inc. フレームワークの構成をベースに各サービスの運⽤を⽀援

Slide 15

Slide 15 text

©2024 Metaps Holdings, Inc. ©2024 Metaps Holdings, Inc. ● ⼀⼈のSREエンジニアが2〜3のサービスを運⽤している ● アラートの発⽣頻度や傾向のトレースがおざなりに ○ 「HTTP 5XXのアラート調査どうなりました?」→ アラートが多すぎてSlackのメッセージを⾒失 う ○ SentryやDatadogなど、アカウントを横断してアラートの傾向‧集計が⾒たい 発⽣した課題

Slide 16

Slide 16 text

©2024 Metaps Holdings, Inc. 2024年9⽉にAWS横断監視ツール srestをリリース

Slide 17

Slide 17 text

©2024 Metaps Holdings, Inc. その上で、今年はインフラ基盤の リアーキテクトに⼒を⼊れました 17

Slide 18

Slide 18 text

©2024 Metaps Holdings, Inc. ©2024 Metaps Holdings, Inc. 何をしたか? ● Terraformディレクトリ構造の再構築 ● Amazon DocumentDBからAmazon OpenSearch Serviceへの移⾏ ● AWS Batchの導⼊

Slide 19

Slide 19 text

©2024 Metaps Holdings, Inc. Terraformディレクトリ 構造の再構築 19

Slide 20

Slide 20 text

©2024 Metaps Holdings, Inc. 従来のディレクトリ設計 ● EC2やS3など、サービス単位でディレクトリを分ける ● 操作ミスが発⽣しても障害範囲を最⼩限に抑えられる ● 複数⼈で作業していても、コンフリクトが発⽣しにくい ● stateがディレクトリ単位の管理となるため、dataの依 存関係が分かりづらい

Slide 21

Slide 21 text

©2024 Metaps Holdings, Inc. 新しいディレクトリ設計 ● networkやstorageといった抽象化したレイヤーごとに ディレクトリを分割 ● dataの依存関係が分かりやすくなった

Slide 22

Slide 22 text

©2024 Metaps Holdings, Inc. ディレクトリ構造の⽐較 ディレクトリを分けない サービスごとに ディレクトリを分割 抽象化したレイヤーで ディレクトリを分割 applyの回数 1回で済む ▲サービス単位で実行 レイヤーの粒度で実行 安全性 ▲低い (影響範囲が広域に及ぶ) 高い 比較的高い tfstateのサイズ ▲非常に大きい (applyの実行速度に影響) 小さい 比較的小さい リソース間の 依存関係 シンプル ▲複雑 比較的シンプル コンフリクト ▲発生しやすい 発生しづらい 比較的発生しづらい

Slide 23

Slide 23 text

©2024 Metaps Holdings, Inc. Amazon DocumentDBから Amazon OpenSearch Serviceへ の移⾏ 23

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

©2024 Metaps Holdings, Inc. AWS Batchの導⼊ 27

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

©2024 Metaps Holdings, Inc. 最後に 31

Slide 32

Slide 32 text

©2024 Metaps Holdings, Inc. システム構成は、要件や規模に 応じてリアーキテクトを検討する ことが重要です 32

Slide 33

Slide 33 text

©2024 Metaps Holdings, Inc. 33