[レポート]ODD (Observability-driven Development)はシフトレフトのためにあるのか？エリートなDevSecOpsパフォーマーになるには (sponsored by Sumo Logic) #PRT283 #reinvent

セッション

スピーカー：Collin Fallwell
セッションレベル：200 - Intermediate
カテゴリ：Migration, Security, Cost Optimization

動画本編

はじめに

AWSの年に一度の祭典 re:Invent 2022に参加してきました。 現地オフラインで Is it ODD to shift left? Becoming elite DevSecOps performers (sponsored by Sumo Logic) というセッションに参加してきました。

セッションの概要は以下となります。

概要

今日の世界では、顧客は一流のデジタル エクスペリエンスを期待しています。遅いアプリケーションや機密データを漏らすアプリケーションは、熱心なユーザーでさえ疎外される可能性があります。このセッションでは、DevSecOps とオブザーバビリティ ドリブン デザインという 2 つの新しいプラクティスを残して、セキュリティとオブザーバビリティを移行するための根底にある議論を探ります。 Fortune 500 の顧客のケース スタディを引用して、Sumo Logic のフィールド CTO が、質の高いサービスを提供するには、データ、ワークフロー、および高度な分析を統合する必要があることについて説明します。グローバルなセキュリティとパフォーマンスに関する洞察の中央ハブがサービス提供を加速する方法と、高品質のサービスを提供するために AWS ランドスケープの統一されたビューが重要である理由をご覧ください。このプレゼンテーションは、AWS パートナーである Sumo Logic によって提供されます。

内容

• エリートな開発者になるにはセキュリティ運用が重要になってくる
• システムの複雑性が増してログの分析が難しくなっている
• そのためにログの集約が必須になってくる

• Kubernetesのようなマイクロサービスを移行した企業の内90％以上は大規模なアウテージまたはセキュリティ侵害を受けている

• 強いプロセスケーパビリティを持つには何が必要か
  • 顧客の声を知る（VOC）
  • プロセスの声を測る（VOP）
  • 特定の閾値をもつこと
  • データの十分なサンプリングレート
  • 有能なプロセスを構築する場合に、測定するのは何かが逸脱していないかを見る
  • それには高解像のサンプリングデータが必要

• プロセスケーパビリティを発展するには何が必要か
  • メトリックスのフレームワークを持つ
  • 既によく知られているCMMI（能力成熟度モデル）の成熟な位置にいても、常に全てのことは進化し続けているため、メトリクスの計測とレポートについても常に発展し続ける必要がある
  • 全てのキューとバックログなくす
  • バトルテストコードを実行し、システムを壊す

• なぜODD（Observability-Driven Development）が必要か？
  • Facebookのあるエンジニアの言葉では、プッシュしたコードからの適切なフィードバックが得られないと、トラブルシューティングや事象の再現に膨大な時間を費やし、その結果疲労しきって会社を去ることになってしますだろう
  • その問題はデベロッパーとプロダクションの関係が欠如していること
  • デベロッパーとプロダクションの関係が強ければ、何が起きているかをすぐに要求することができる 　　

  • プロダクションをテストすることで、開発サイクルを高速に回すことができ、仮説ではなくフィードバックによって開発をすすめることができる

  • 弱いプロセスを表面に出すことができる 　　

  • ObservabilityはDevOpsを加速するためだけではなく、FinOpsやSecOps、BIも対象となる

  • ODDはTest-drived Development (TDD)を拡張したもの

  • 予測したアウトカムを測定して、変更を加え、さらに測定を続けていく 　　

• ODDのベストプラクティス

  • 機能レベルでのメトリクス、トレース、ログとイベントの統合が必要
  • VOC（顧客の声）を反映する
  • 継続的にプロセスと経験を計測する
  • ゆるいコードを避ける、重いワークロードを避ける
  • 何のアップストリーム/ダウンストリームが顧客体験を逃しているか、リスクを軽減できるかを特定する 　　
• メトリクス計測のベストプラクティス
  • アンチパターン - 3〜4の標準偏差をしきい値としたアラート
  • コンテキストの欠落が生じる
  • 推奨 - 2〜3の標準編差をしきい値としたアラート 　　
• コードとしてのベストプラクティス
  • OpenTelemetry SDKを組み込んで、ロギング、属性、タギングの標準化を実施する
  • Domain-driveプログラミングを実施する
  • クリーンなコード、aspect-orientedプログラミングを実施する 　　
• もし必要であれば、既存コードを改良する 　　

• エリートパフォーマーとは

  • 1日に複数のデプロイをオンデマンドに実行
  • 1日以下の変更のリードタイム
  • 1日以下のサービスリストアのタイム
  • 変更失敗率 0-15% 　　
• 必要なパフォーマンスメトリクス
  • リードタイム、デプロイ頻度、変更失敗率、リストア時間の4つのメトリクスがスタートポイント
  • もっと詳細な情報を知りたい場合は、GSAウェブサイトのDevSecOpsを参照すると、より詳細なメトリクスを確認できる 　　
• ゴールまでのパイプライン
  • プロジェクトを標準化する。テストやコードシップの方法は一つにする
  • プルリクエストとマージを自動化する
  • コミットごとにテストする
  • いつでもデプロイ出来るようにテスト毎にビルドする
  • 環境依存しないようにする
  • CIプロセスで継続的なフィードバックを得る
  • エンジニアは短期間でタイトなフィードバックを得る
  • よくテストされ、バージョン管理されたコード 　　
• ゴール1 自動化、階層、コントロール
  • CIのベストプラクティス
  • プロジェクトはプロジェクトタイプを定義するYAMLなどのコンフィグファイルを必要とする
  • レポジトリはいくつかのプロジェクトタイプを持つ
  • これらのベストプラクティスはJeff DickeyのThe 12-Factor CLI Appを参照すると良い 　　 　　
• ゴール2 フィードバックを得るためのコミュニケーションパイプライン
  • コミュニケーションのベストプラクティス
  • 重要なフィードバックは出来るだけ早く提供する
  • 同じ失敗は何度も通知せず一度だけにする
  • 圧倒されない程度で出来るだけコンテキストを多く与える 　　 　　

まとめ

このセッションでは、Observability-driven Developmentのための開発者に求められる要素やベストプラクティスについて学ぶことができました。
Sumo LogicはいわゆるSIEM製品として活用される製品ですが、セキュリティのみならず、オブザーバビリティ、ビジネスインテリジェンスを含めた、よりビジネスをドライブすることにフォーカスした包括的なデータ分析に力をかけているように思われるセッション内容でした。
特に、開発者とビジネスを繋ぐ視点から、Observability-driven Developmentというキーワードで、何を計測するべき（何のメトリクス）かを考えるのにヒントとなる非常に興味深い内容だと感じました。