運用を犠牲にせずコストを制御し事業成長を支える B2B SaaS ID管理基盤におけるS3 Tableのログストレージ活用

AWS AI Ready Platform Day Tokyo
https://aws-experience.com/apj/smb/event/85dee511-6612-4e58-b2d2-aa207a5cd93d

運用を犠牲にせずコストを制御し事業成長を支える B2B SaaS ID管理基盤におけるS3 Tableのログストレージ活用

高井 真人
ソフトウェアエンジニア

Transcript

1. AWS AI Ready Platform Day Tokyo 運⽤を犠牲にせずコストを制御し事業成⻑を⽀える B2B SaaS ID管理基盤におけるS3 Tableのログストレージ活⽤ 株式会社カミナシ ⾼井 真⼈
2. ⾃⼰紹介 高井 真人 博士（工学） 株式会社カミナシでID管理・認証認 可基盤の開発をしています。 好きなRFCは8628。 X：@manaty0226
3. 今⽇話すこと AI Readyなデータ基盤であること • • 蓄積し続けるデータに対して、予測可能かつ制御されたコストによる運⽤ AIモデルが効率的にデータを処理できるよう読み出しやすい形式の提供 オブザーバビリティにおける AI Readyなデータ基盤の価値 • • 機械だけでなく⼈にも親和性の⾼いデータでシステムの推測可能性を⾼める 制御されたコストによるエージェントの閉ループ構築
4. カミナシとは
5. Mission ノンデスクワーカーの 才能を解き放つ
6. ⽇本における 労働⼈⼝の割合 ノンデスクワーカーは⽇本の労働⼈⼝の半数以上。 私たちの⽣活は、あらゆる場⾯で ノンデスクワーカーに⽀えられている デスク ワーカー 43% 製造業 飲⾷店 スーパー‧⼩売 設備‧清掃 福祉施設 旅客‧運輸 ノンデスク ワーカー 57% ※ 独⽴⾏政法⼈労働政策研究‧研修機構「職業別就業者数」より当社算出
7. ノンデスクワーカーの働く環境 私たちの当たり前が 当たり前ではない世界。 プライベートではスマホを使いこなす⼈が、職場に⾏くととなぜか 紙とペンの世界にタイムスリップしてしまいます。
8. “現場の基盤” カミナシ 3つの領域をまたぐデジタルインフラに Method 作業 電⼦帳票 Men マニュアル‧研修 ⼈ Machine コミュニケーション 設備 設備カルテ 1つのアカウントで複数のシステムを利⽤。運⽤の負担軽減とセキュリティ向上
9. 「カミナシ ID管理」プロダクトビジョン 地球上でもっとも ノンデスクワーカーに寄り添った アイデンティティプロバイダーへ
10. なぜID管理基盤のコストはサービス成⻑にクリティカルに影響するのか ID管理基盤はすべてのサービスがあらゆる場⾯で依存するため、サービス全体の成⻑ に⽐例して受け⼊れるべきリクエスト量が増加する テナント#1 … ログイン/ログアウト アクセストークン検証、更新 ユーザーやマスタ情報の参照 認証認可 ユーザー管理 テナント#n 組織マスタ管理 …
11. オブザーバビリティとコスト
12. オブザーバビリティの捉え⽅ Kalmanは1960年の論⽂で、ある特徴をオブザーバビリティ と名付け、数学的制御システムを説明しました。制御理論で は、オブザーバビリティとは、外部出⼒の知識からシステム の内部状態をどれだけうまく推測できるかの尺度として定義 されています。 引用：C. Majors, Liz Fong-Jones, G. Miranda 「オブザーバビリティエンジニアリング」O’Reilly, Jan. 2023,
13. Software Engineer as a Kalman Filter オブザーバビリティシグナル e.g. トレース‧メトリクス‧ログ 真の 出力 真のシステム状態 e.g. ユーザーリクエスト 入力 推定誤差 できるだけ一致させたい 推定した システム状態 推定した 出力 誤差が小さくなるようにフィードバック
14. オブザーバビリティシグナルのコスト要因 シグナルの取り込み シグナルの検索 ストレージ シグナルの保管
15. オブザーバビリティシグナルのコスト要因 • • 取得条件の絞り込み ダウンサンプリング シグナルの取り込み シグナルの検索 ストレージ • • シグナルの保管 保管期間の短縮 ストレージティアの調整 • • • インデックス設定 検索期間の限定 データ量制限
16. 主要なオブザーバビリティシグナルのコスト削減⽅法 メトリクス ディメンションの削減 ダウンサンプリング トレース ヘッド/テールサンプリング スパンフィルタリング ログは事象のwhyを⽰すことが多く重要な情報を含むため他の2つに⽐べて サンプリングすることが難しい ログ 重複ログの削減 ログレベルによるフィルタ ログの保存期間削減
17. CloudWatch Logsのコスト要因 CloudWatch Logsにログを取り込む たびにかかるコストで回避が困難 シグナルの取り込み シグナルの検索 ストレージ 検索期間によってコストが 跳ね上がる可能性 シグナルの保管 保存期間の調整やIntelligent-Tieringの利⽤でコ スト制御可能
18. ログストレージへのS3 Tables活⽤
19. Amazon S3 TablesとCloudWatch Logsをアプリケーションログストレージとして利⽤する際の⽐較 CloudWatch Logs コスト ログボリュームと保管期間に ⽐例して急峻に増加 スキーマ定義 不要 パイプライン ログルーターから直接投⼊ ストレージ運⽤ ストレージ運⽤の必要なし Amazon S3 Tables CloudWatch Logsと⽐較して 取り込み‧保管ともに価格を 抑えられる 必要 S3 Tablesへの投⼊や コンパクション運⽤は基本的 にマネージドで完結
20. ログパイプライン構成の⽐較 CloudWatch Logs ログルーターから直接 CloudWatch Logsに配信 ログルーター CloudWatch Logs S3 Tables+Firehose Data Firehoseなどを経由して 投⼊ログファイルが⼩さくな りすぎないよう バッファリングしながら S3 Tablesに配信 ログルーター Data Firehose S3 Tables Athena
21. Amazon S3 TablesとCloudWatch Logsのコスト⽐較 ログの取り込みコスト CloudWatch Logs ログの保管コスト 標準 標準 $0.76 / GB $0.033 / GB Archive Instant Access $0.0066 / GB 取り込みコストの差が⼤きい S3 Tables+Firehose Direct PUT + pinback compaction $0.098 / GB 標準 $0.0288 / GB Archive Instant Access $0.0058 / GB ※ 2026年7⽉時点の公式ページ記載の価格情報（東京リージョン）です。実際の価格は適宜ご確認下さい。
22. CloudWatch Logsから S3 Tablesへの移⾏
23. 実運⽤も踏まえた段階的な移⾏ S3 Tablesに移⾏した後に実運⽤で致命的な運⽤⾯やコスト⾯での想定外事象が 発⽣した場合、S3 Tablesへ投⼊したログを再度CloudWatch Logsに移⾏して切 り戻すコストが⼤きい。 そこで、CloudWatch LogsとS3 Tablesに並⾏書き込みしながら実運⽤を経て段 階的に移⾏。 切り戻しのために ⼆重書き込み CloudWatch Logs ログルーター Data Firehose S3 Tables Athena
24. CloudWatch LogsとS3 Tablesの適材適所 すべてのログをS3 Tablesだけに送るのではなく、エラーレベル以上のログは CloudWatch Logsに送り即時確認したり、CloudWatch Alarmと連携してSlack にアラートする。 CloudWatch Logs CloudWatch Alarm Grafana S3 Tables Athena ID管理 API ログルーター サーバー Data Firehose
25. S3 Tablesへの移⾏効果
26. S3 Tablesへの移⾏に伴うコスト最適化効果 事前の試算のとおりコストの主要因であったCloudWatch Logsへの取り込みコスト をFirehoseとS3 Tablesへの移⾏で⼤幅に削減することができた
27. オブザーバビリティ基盤を利⽤したAIによるパフォーマンス改善サイクル クエリコストの低いS3 TablesとAthenaのスキャンバイト制限によって、予測可能で 制御されたコストによるエージェントループが可能となり、Grafanaへ安全にアクセ スするskillsをつくったことでチームの誰もが簡単にログ‧トレース‧メトリクスを横 断的に探索できるようになった。 IAM一時認証情報からGrafanaサービスアカウント の短生存期間トークンを取得してアクセス メトリクス トレース OpenTelemetry Collector Grafana ID管理 APIサーバー ログルーター Data Firehose S3 Tables Athena
28. AIエージェントの⽀援を得たことによって近づくオブザーバビリティの理想像 もっとも⻑く在籍する⼈が最⾼のデバッガーであるという ことはなくなりました。 もっとも好奇⼼が強く、最も粘り強く、新しい分析ツールを もっとも使いこなす⼈が最⾼のデバッガーになりました。 引用：C. Majors, Liz Fong-Jones, G. Miranda 「オブザーバビリティエンジニアリング」O’Reilly, Jan. 2023,
29. まとめ • AI Readyなデータ基盤の１つの要件はコストが予測可能で制御されていること • オブザーバビリティにおいては、機械可読性だけでなく⼈間にとってもあつか いやすい形式であることが望ましい • CloudWatch Logsでは取り込みコストが⽀配的なため、取り込みコスト最適化 が⾒込めるS3 Tablesをアプリケーションログストレージとして採⽤ • コスト削減したことでAIエージェントを存分に活⽤してシステムのボトルネッ クを探索できるようになった
30. 株式会社カミナシ https://kaminashi.jp