Ops JAWS Meetup#24 参加レポート

はじめに

Ops JAWS Meetup#24 にオフライン参加したので、参加レポートを簡単にまとめてみました

今回のテーマは、SaaS開発におけるテナント管理方法、GitHub x TerraformでのIAM管理効率化、静的安定性の高いアーキテクチャ、ビジネス要件を意識したオブザーバビリティと、非常に濃密な内容でした！

動画も公開されていますので是非見てみてください
酒徳さんのセッションではデモンストレーションもありますので、動画を見ていただく方がわかりやすいと思います

Multi-Account Observability for SaaS providers

• 概要

  • AWS本社でプリンシパル ソリューションズ アーキテクトをされている酒徳さんのセッション
  • DevDayでの発表のダイジェスト版
  • SaaSを設計するモデルが進化してきている中で、デプロイや監視、運用、請求モデルの作り方などを考える必要がある
  • 今回はテナントをどうやって監視すればいいのか、に主にフォーカスを当てて話す

• コントロールプレーンとデータプレーン

  • コントロールプレーン
    • 管理者向けのアプリケーション
    • 認証認可や課金の管理などを行っている
  • データプレーン
    • アプリケーションの機能を提供する
  • コントロールプレーンとデータプレーンを物理的にどうやって配置するのか、を今回は主に話す

• 3つのモデル

  • 従来のSaaSモデル
    • コントロールプレーンとデータプレーンを同じ場所に配置
      • ここ数年は別々の場所に配置（スプリットプレーンモデル1~3）で考えることが多い
  • モデル＃１
    • アカウントを分けることで、ポリシーをコントロールプレーンとデータプレーンで完全に分けたい場合に適切
  • モデル＃２
    • データへのアクセスはサービスプロバイダーが提供する
    • データはSaaSプロバイダー側に上げなくて済むモデル
  • モデル＃３
    • すぐにはオンプレを廃止できないが、徐々にクラウドに移行するときに使われるパターン

• スプリットプレーンアーキテクチャの課題

  • アクセスコントロール
    • マルチアカウントの管理をどうやって行うか
  • アカウントをまたいだ開発運用
    • クロスアカウントにおいてパイプラインをどうやって使うか
  • テナント管理
    • 複数アカウントをまたいだうえで、各テナントでユーザーのアクティビティ追跡を行うことが複雑になってしまう
  • 以降、テナント管理の課題にフォーカスしていく

• OTel（オーテル）とADOT

  • OTel
    • OpenTelemtryの略
    • ログ、トレース、メトリクスなどを収集し、管理する手法
    • アプリケーションに影響を与えずにオブザーバビリティを提供できるようにする
  • ADOT
    • AWS Distro for OpenTelemetryの略
    • AWSが提供しているOTel
    • レシーバー
      • ソースからのシグナルを受信
    • プロセッサー
      • シングルデータのプリプロセッシング
    • エクスポーター
      • データをターゲット（AWSサービス）に送信する
      • AWSのネイティブサービスを多くサポートしている
    • ECSなどAWSのサービスを使用していると、コンソール画面からワンクリックでADOTを有効化できる
      • Lambdaの場合はレイヤーにADOTをデプロイすることで、簡単に実装することができる

• デモンストレーション
  • それぞれのアカウントでデータに対して属性やタグなどを付与させ、オブザーバビリティデータを一つのアカウントに集約させるような構成
    • SaaS設計をするうえでよくあるハマりポイントとして、分析するときに無料会員を追う手段が無かったりする
    • 事前に属性やタグをつけることで、そういった事態を防ぐことができる
  • データ集約にはCWクロスアカウントオブザーバビリティを使用する

• まとめ

  • SaaSをAWS上で設計する場合、すでに最適なモデルがあるはず
  • それらを臨機応変に活用していこう！

• QA

  • 集約アカウントとそれ以外のアカウントの請求について
    • 実はCWクロスアカウントで集約する側には料金が発生しない。なので、倍のコストが発生することは無い
  • クロスアカウントオブザーバビリティを利用しているケースで、SNSでのアラート通知構成のおすすめはどうなるでしょうか？各アカウント内に閉じる形か親アカウント側で集約管理・通知すべきか。
    • どれだけ早く通知を受けたいか、どれだけ受け取りたくないか、によって設計すべき
    • とりあえず親アカウントでやってみるのがいいと思うが、ケースバイケースだと思う

複数プロダクトを管理する AWS Organizations における AWS IAM Identity Center を GitHub x Terraform でいい感じに運用したい

• 概要

  • MIXIの濱野さんのセッション
  • IAM Identity Center におけるIAMの管理方法を現在設計中とのこと
  • GitHub x Terraformでいい感じにできる見通しが立ったので、その設計をご紹介

• IAM Identity Centerとは

  • AWSアカウント、その他ビジネスアカウントのSSOを提供するサービス
    • 各AWSアカウントへのコンソールログインが便利になる
      • 特定のポータル画面でアカウントが一覧表示される
    • IDプロバイダーと連携できる
      • 退職者のアカウント削除し忘れなどを防ぎやすい
    • AWS CLI v2利用によって、一時的な認証情報を利用することができる
      • 事前にAWS CLIのプロファイル設定をしておく
  • Orgabizations利用が前提

• AWS IAM Identity Center利用における運用

  • 現状は各事業部ごとにアカウントを分けて、IAM Identity Center で管理している
  • 課題：特定のアカウントでしかIAM管理ができない
    • 依頼ベースでの設定でもいいが、設定を誤った場合の影響が怖い
    • IAM設定をIaC化すればいい感じにできそう！ということで現在設計中。。。

• GitHub x Terraform（現在設計中）
  • GitHubの採用理由
    • MIXIの中でデファクトスタンダードとして使用されている
    • プルリクのマージ条件に特定ユーザ、チームのApproveを強制できる
  • Terraformの採用理由
    • Terraformの採用率が高い
    • Terraform Cloud を使えばCI/CDをマネージドにできる
  • 全体設計
    • 事業部毎にディレクトリを切ってtfファイルを管理
    • CODEOWNERSを使用することでコードオーナーのApproveを強制できる
    • AWSとTerraformはOIDC連携し、Workspace毎のロールで操作権限を絞る
      • apply時の影響を抑えることができる

• 各事業部で使用してもらうための工夫
  • ドキュメントをしっかり整備する
  • 相談窓口を整える
  • IAM設定以外をラップしたmoduleを用意する
    • 各事業部がIAM以外のリソースを意識しないでいいようにする

静的安定性を考える、依存しないアーキテクチャ

• 概要

  • クラスメソッドの吉井さんのセッション
  • 静的安定性を意識することで、障害に強いアーキテクチャを作ろう！という内容

• 静的安定性とは

  • システムが静的な状態で動作し、依存関係に障害が発生しても、通常通り動作し続けることができる（AWSのサイトから引用）

• 重要なことその1：AWSのコントロールプレーンに依存しないアーキテクチャを考えることが重要！

  • データプレーンと比較するとコントロールプレーンは複雑なので障害が起こりやすい
  • 例）NATGWを各AZにプロビジョニングしておく、その際にAZは3つ使う
    • なぜか？
      • AZ障害に近い障害が発生しているときに、サブネット追加作成のAPIなどが動くとは考えにくい
      • 障害手順の中に、コントールプレーンのAPIをたたく操作はいれないほうがいい
      • 事前にNAT GWを作っておくことが、静的安定性のあるアーキテクチャ

• 重要なことその2：北米リージョンに依存しない

  • 例えばIAMでは、コントロールプレーンが北米リージョンにある
    • ほかにも北米リージョンにコントロールプレーンがあるAWSサービスは割とある
  • 復旧処理の中に北米リージョンにコントロールプレーンがあるサービスのAPIをたたこうとしない

• 重要なことその3：リソース不足への対応

  • AWSのリソースは無限ではないことを忘れない
  • スケールアウトするときなどに使用するリソースを固定しすぎない方がいい
    • 例）AutoScalingでインスタンスタイプを指定するのではなく、スペックを指定することで幅を持たせる

• 重要なことその4：サービス間に依存しない
  • あるシステムが落ちても、他のシステムに影響が及ばないようにする
    • キューイングやサーキットブレーカーなどを実装する

監視なのにビジネスメトリクスや顧客体験を見ろって言うけど、どういうこと？

• 概要

  • NewRelicの相澤さんのセッション
  • ビジネス観点まで考えたオブザーバビリティをどうやって考えていくか

• ワーナーの言葉「監視という考え方を捨てよ」

  • システムを運用していくうえで、監視だけでは不十分
  • 全体的なアプローチ、まさに「オブザーバビリティ」を考えるべき

• 監視からオブザーバビリティへ進化

  • インフラの監視
    • 一番最初に行われていることが多い監視
  • アプリケーションの監視
  • 顧客体験の監視
    • ここの3つまでできる状態が、「オブザーバビリティがある」かどうかの基準の一つ
  • ビジネス監視
    • サービスレベルや機会損失
    • ここまでできれば「オブザーバビリティがある」と言える！

• システムKPIとビジネスKPIを掛け合わせる

  • システムのパフォーマンスが利用者、ビジネスにどれだけ影響を与えているのかがわかるように説明することが効果的
    • Web分析とソフトウェア分析の間を補完してあげる
  • B2Cだけじゃなく、社内システムであってもユーザーの不満やサービスレベルを考えるべき
    • 例）日々の打刻のタイミングでレスポンスが遅くなってしまっていないか

• QA
  • アプリケーションレイヤー以上の監視になりますと運用担当者だけでは対応できず、アプリケーション開発者の協力も不可欠だと思います。アプリケーション開発者とどうやって協力体制を築けばよろしいでしょうか？またアプリケーションレイヤー以上の監視対応も運用者側(SREやインフラエンジニア)が責任をもって対応するべきでしょうか？
    • 事業側にオーナーシップをもってやってもらうことが重要だと思う
    • アプリ側の導入負荷を下げることが重要だと思う