Slide 1

Slide 1 text

さくらのIaaS基盤のモニタリングとOpenTelemetry 2025-07-05 Open Source Conference 2025 Hokkaido さくらインターネット株式会社 クラウド事業本部 藤原俊一郎

Slide 2

Slide 2 text

自己紹介 @fujiwara (X, GitHub, Bluesky) @sfujiwara (hatena, mixi2) 2011〜2024 面白法人カヤック 2025-02〜 さくらインターネット ISUCON 優勝4回 / 運営(出題)4回 github.com/kayac/ecspresso github.com/fujiwara/lambroll

Slide 3

Slide 3 text

さくらのIaaS基盤 さくらのクラウド 仮想サーバー(VM)基盤 データプレーンは OSS を活用 Linux, QEMU, KVM, LVM, Open-iSCSI, etc... コントロールプレーンは自社開発のソフトウェア + OSS nginx, Apache httpd, PHP, Perl, Go, MySQL, RabbitMQ, etc...

Slide 4

Slide 4 text

さくらのIaaS基盤のアーキテクチャ(初期: 2011〜2020年頃まで) モノリシックなAPIサーバー + script群 PHP(API) + Perl + Shell 例: VM起動の流れ(レガシー) 1. ユーザーがAPIサーバーにリクエスト 2. APIサーバーが具体的な起動方法を決定 DBの情報を見てVM起動ホストを選択 実行するためのコマンドラインを生成 (Perl / Shell でQEMU, KVM を操作) 3. リモートでコマンドを実行してVMを起動 ストレージ(iSCSI target/initiator)やネットワークも同様に操作

Slide 5

Slide 5 text

例: VM起動の流れ(レガシー) 物理ホスト群 batch API リモート実⾏ ユーザー VM 起動処理 ホスト選択 コマンド⽣成 DB 情報収集バッチ ホスト1 ホスト2 ホスト3

Slide 6

Slide 6 text

さくらのIaaS基盤のアーキテクチャ(2020年頃〜) 新しいアーキテクチャに段階的に移行 モノリシックなAPIサーバーからマイクロサービスへ API: PHP (将来的には Python+Django?) 各コンポーネントの具体的な責務をAPIから分離(マイクロサービス化) 例: VMを起動するべきホストの選択, 起動コマンドライン生成 Goで書かれたマイクロサービスに対してAPIからはgRPCでリクエスト VM, ストレージ, ネットワークなどの各コンポーネントをマイクロサービス化

Slide 7

Slide 7 text

物理ホスト群 API ホスト3 ホスト2 ホスト1 gRPC boot status status status VM bridge ホスト選択 ユーザー VM 起動処理 VM agent VM agent VM agent

Slide 8

Slide 8 text

さくらのIaaS基盤のモニタリング ホスト(物理サーバー)やネットワーク機器のモニタリングは以前から Zabbix を利用 マイクロサービス化に伴いマイクロサービスやミドルウェアのモニタリングも必要に Prometheus + Grafana を導入 各マイクロサービス: prometheus exporter を実装 /metrics エンドポイントを実装しメトリクスをエクスポート Prometheus: マイクロサービスのメトリクス収集 Grafana: 可視化

Slide 9

Slide 9 text

さくらのIaaS基盤のモニタリングの課題 Prometheus + Grafana を入れたものの…… ダッシュボードの整備が大変 アラートは未設定 (Prometheus Alertmanager) 集めることは集めたが、メトリクスをあまり有効に使える状態ではなかった 監視基盤を OSS で整備し続けるのはそれなりに大変(運用コスト)

Slide 10

Slide 10 text

Mackerel + OpenTelemetry を導入 Mackerel 株式会社はてなが提供するサーバー監視、オブザーバビリティSaaS mackerel.io Mackerel で取得できるメトリクスは3種類 サーバーにインストールしたagentが取得するメトリクス(host metrics) サーバーに紐付かないメトリクス (service metrics) ラベル付きメトリクス (OpenTelemetry互換) OpenTelemetry ログ、メトリクス、トレースを統一的に収集・送信するための OSSの観測可能性フレームワーク

Slide 11

Slide 11 text

Mackerel + OpenTelemetry を導入 要求 prometheus exporter はそのまま使いたい Mackerel にメトリクスを送信したい 解決策 otel-collector (OpenTelemetry Collector) を利用 1. prometheus receiver でメトリクスを収集(scrape) 2. (必要に応じて) processor でメトリクスを加工 3. otlp exporter で Mackerel に送信 これで prometheus の資産を生かしつつ同時に Mackerel にもメトリクスを送信できる

Slide 12

Slide 12 text

Mackerel OpenTelemetry Collector scrape scrape scrape VM 管理サービス /metrics ストレージ管理サービス /metrics ネットワーク管理サービス /metrics prometheus receiver processors otlp exporter otlp endpoint

Slide 13

Slide 13 text

OpenTelemetry Collector を用意する otel-collector は OpenTelemetry のメトリクス、ログ、トレースを収集・加工・転送する ためGo製のOSS 構成要素 receiver: 収集 prometheus, otlp, jaeger, fluentdforward, hostmetrics... processor: 加工 batch, memory_limiter, transform... exporter: 転送 otlp, prometheusremotewrite, file, debug... extension: 追加機能 health_check, pprof...

Slide 14

Slide 14 text

OpenTelemetry Collector をどう用意するか 実際には receiver, processor, exporter から必要なものを組み合わせて使う あらかじめ公式で用意されたdistribution OpenTelemetry Collector ("otelcol") OpenTelemetry Collector Contrib ("otelcol-contrib") OpenTelemetry Collector for Kubernetes ("otelcol-k8s") OpenTelemetry Collector OTLP ("otelcol-otlp") OpenTelemetry Collector eBPF Profiler ("otelcol-ebpf-profiler") 全部入り = contrib

Slide 15

Slide 15 text

OpenTelemetry Collector をどう用意するか 公式の distribution を使うのが簡単だが… 提供されているものでは欲しい機能が足りないことがある 全部入りの contrib は大きい(バイナリが300MB以上) 不要なコンポーネントによるセキュリティリスクなども → 必要なコンポーネントだけを組み合わせてビルドするのが推奨 https://opentelemetry.io/docs/collector/custom-collector/

Slide 16

Slide 16 text

OpenTelemetry Collector を自分でビルドする 公式に用意された ocb (OpenTelemetry Collector Builder) を使えば簡単 https://github.com/open-telemetry/opentelemetry-collector/tree/main/cmd/builder dist: name: otelcol-custom description: Local OpenTelemetry Collector binary output_path: /tmp/dist exporters: - gomod: github.com/open-telemetry/opentelemetry-collector-contrib/exporter/alibabacloudlogserviceexporter v0.109.0 - gomod: go.opentelemetry.io/collector/exporter/debugexporter v0.109.0 receivers: - gomod: go.opentelemetry.io/collector/receiver/otlpreceiver v0.109.0 processors: - gomod: go.opentelemetry.io/collector/processor/batchprocessor v0.109.0 providers: - gomod: go.opentelemetry.io/collector/confmap/provider/envprovider v1.15.0 - gomod: go.opentelemetry.io/collector/confmap/provider/fileprovider v1.15.0 - gomod: go.opentelemetry.io/collector/confmap/provider/httpprovider v0.109.0 - gomod: go.opentelemetry.io/collector/confmap/provider/httpsprovider v0.109.0 - gomod: go.opentelemetry.io/collector/confmap/provider/yamlprovider v0.109.0

Slide 17

Slide 17 text

sacloud-otel-collector さくらのクラウド向けに OpenTelemetry Collector を用意しました(OSS) https://github.com/sacloud/sacloud-otel-collector 用意した理由 さくらのクラウド内部、外部ともに OpenTelemetry エコシステムを採用 モニタリングスイート(β)を提供している 利用者が独自のログやメトリクスを送信する 他のマネージドサービス(AppRun, Database Appliance...)からメトリクスやロ グを送信する VMのメトリクス(CPU, メモリ, ディスク, ネットワークなど) を送信する 公式ビルドを用意して手軽に使ってもらいたい

Slide 18

Slide 18 text

sacloud-otel-collector の今後 現在は一般的に利用できるコンポーネントを組み合わせてビルドしたものを提供中 リリースバイナリ (linux/amd64,arm64) Dockerイメージ (linux/amd64,arm64) ghcr.io/sacloud/sacloud-otel-collector 今後は さくらのクラウドのマネージドサービス用の receiver, exporter VM 上で起動した場合にモニタリングスイートの認証情報を自動設定 など、さくらのクラウド向けに特化した機能を追加していきたい

Slide 19

Slide 19 text

まとめ IaaS基盤のモニタリングを Mackerel + OpenTelemetry で再整備中 OpenTelemetry Collector を使って Mackerel にメトリクスを送信 sacloud-otel-collector を OSS として公開しました 今後はさくらのクラウド向けに特化した機能を追加していく予定

Slide 20

Slide 20 text

No content