【レポート】Open-source observability at AWS − 可観測性を支える OSS と AWS の『いま』を知る #AWS-35 #AWSSummit

2021.05.19

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

本記事は、AWS Summit Japan 2021のセッション動画、「AWS-35: Open-source observability at AWS − 可観測性を支える OSS と AWS の『いま』を知る」のレポート記事です。

セッション概要

モダンなシステム開発・運用の現場において可観測性を確保することの重要性が日々高まっています。とはいえ、可観測性に関連する OSS は変化も速く、そのキャッチアップには手間と時間がかかります。AWS 上での可観測性を支える OSS の「いま」を本セッションでクイックに学んでいきましょう。

スピーカー

アマゾン ウェブ サービス ジャパン株式会社 Container Services Sr. Product Developer Advocate Tori Hara 氏

セッションページURL

セッション内容

可観測性(Observability)とは

あのとき、どこで、何が起きていた︖ を知る力

クラウド上でアプリケーションを構成する場合、それがマイクロサービスアーキテクチャかどうかに関わらず、一定程度複数のコンポーネントに分かれて構成されることはもはや「当たり前」です。可観測性の確保というのは、そのような状況下において、「あのとき、どこで、何が起きていた︖」というのをどうやって知るのかということです。

可観測性(Observability) の確保の基本は三つの柱

ログ

  • システム内で発生したイベント情報
  • 例: アクセスログ、エラー情報、…

メトリクス

  • ある時点でのなんらかのシステム状態を表現する数値情報
  • 一定間隔ごとの時系列データとして記録される
  • 1つ以上のディメンションやラベルで識別される
  • 例: CPU使用率、エラー率、ストレージ残容量、…

トレース

  • 1つのトランザクションを複数のシステムで構成するフロー情報
  • トランザクションごとにユニークな識別子を持って記録
  • 例: あるHTTPリクエストの受け取りからレスポンスまで

AWS 上での可観測性の確保⽅法には多様な選択肢がある

AWS ネイティブサービス

  • ログならCloudWatch Logs
  • メトリクスはCloudWatch
  • トレースはX-Ray

OSS ベースのサービス、OSS でのユーザ⾃⾝によるDIY

なぜOSSを使うのか?
  • 個人開発者にとって…
    • 実験の容易さ、自由度
    • コミュニティ
  • 企業にとって
    • 車輪の再発明を防げる
    • OSS技術の価値をダイレクトに享受できる
    • 採用戦略。OSS好きの優秀な開発者を採用できる
    • オンプレミスからクラウドへのマイグレーション
    • ハイブリッドクラウド(パブリッククラウドとオンプレミスの共存)
    • 自身で管理するレイヤを(ネイティブサービスよりも)多くしたい

ユーザがOSS での可観測性確保を⽬指す際に直⾯する課題を解決するために、AWS は複数のアプローチで取り組んでいる

OSS エコシステムへの貢献

  • aws-fluent-plugin-kinesis
    • Fluentdプラグイン
    • FluentdからKinesis Data StreamsやKinesis Data Firehoseにログを転送できるようにする

OSS 本体やエコシステムへの貢献

  • Fluent Bit向けにも公式プラグインを提供
  • AWS for Fluent Bitコンテナイメージの公開
    • aws-for-fluent-bit
    • Fluent Bit本体とプラグインは、それらのバージョン更新に追随して都度パッケージするのが手間という管理コストの課題があった。前述の公式プラグインも同梱したコンテナイメージを提供することでこの課題を解決
  • Fluent Bit本体へのコントリビューション
    • 前述の公式プラグインの機能をC実装でコア機能化、プラグイン不要に
    • S3への転送もコア機能実装
    • SigV4実装 (各AWSサービスに転送する際に使うIAM認可に必要)
    • その他
  • Cortexのパフォーマンスやスケーラビリティの改善
  • AWS Distro for OpenTelemetry(ADOT)
    • 現時点でパブリックプレビュー
    • OpenTelemetryはCNCF 管理のOSS・プロジェクトであり、テレメトリデータ(ログ/メトリクス/トレース) のAPI標準仕様の策定、実装を行なっている
    • OpenTelemetryの仕様に則ったオープンソースのSDK、エージェント
    • ADOTのSDKをアプリに組み込む or ADOTのエージェントを使うと、AWSネイティブなサービス、OSSベースのAWSサービスやOSSを自分で実行管理しているもの、さらにパートナー企業が提供しているサービスにテレメトリデータを送ることができる

OSS ベースのサービス・機能の提供

  • FireLens for ECS aws35-firelens-for-ecs

    • ログ転送用のイメージを自前で管理することなく、各種サービスにログを転送できる
  • Firelens for EKS Fargate aws35-firelens-for-eks-fargate

    • ログ転送設定をk8sのConfigMapに書くだけで、各種サービスにログを転送できる
  • PrometheusフォーマットのメトリクスをCloudWatchで収集、可視化できるように
    • CloudWatch Agentで収集、Prometheusサーバーの運用が不要に
      • メトリクスの長期保存、高可用性の確保を実現
    • 可視化ツールを統一できる
  • Amazon Managed Service for Prometheus(AMP)
    • 現時点でパブリックプレビュー
    • 前項とは逆で、Prometheus+Grafanaにツールを統合したい要件の場合にフィット
    • Prometheusのマネージドサービス
    • オンプレミスからのPrometheusメトリクスも収集できる
  • Amazon Managed Service for Grafana(AMG)
    • 現時点でパブリックプレビュー
    • 前項AMPの要件に加えて、Grafanaサービスの構築・運用負荷を低減したい場合にフィット
    • Grafanaのマネージドサービス
    • Prometheusメトリクスを可視化できるのはもちろん、CloudWatchやX-Rayなど各種AWSネイティブサービスの情報も可視化できる
    • AWS SSOやCloudTrailとの連携もできる

One Observability Demo ワークショップおすすめだよ

紹介したサービスやOSSを利用して、AWS上で可観測性を確保する方法を手を動かしながら学べます。

感想

セッションの中で登場した各種サービスやツールの名前は知ってるものがほとんどだったのですが、それぞれがどういう位置づけ、文脈で登場したものなのかの説明がわかりやすく、整理できてよかったです。これからOSSベースのサービスで可観測性の確保を考えている方は是非一度セッション動画をご覧になってください。