クラウドを使う側から、作る側へ / 大吉祥寺.pm 2026前夜祭

大吉祥寺.pm 2026 前夜祭
https://fortee.jp/dai-kichijojipm-2026

Links:

- https://github.com/kayac/ecspresso
- https://github.com/fujiwara/lambroll
- https://speakerdeck.com/fujiwara3/osc-hokkaido-2025
- https://opentelemetry.io/docs/collector/custom-collector/
- https://github.com/open-telemetry/opentelemetry-collector/tree/main/cmd/builder
- https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/d6b5753c-c4eb-4ee6-92d0-21b3fa945a82/8bcd22f0/20260327_policies_gov_cloud_outline_01.pdf
- https://speakerdeck.com/kazeburo/sakura-techday-develop-govcloud-and-the-team?slide=7
- https://knowledge.sakura.ad.jp/49327/
- https://github.com/sacloud/sacloud-otel-collector
- https://github.com/mackerelio/opentelemetry-collector-mackerel
- https://github.com/fujiwara/simplemq-cli
- https://github.com/fujiwara/sakura-secrets-cli
- https://github.com/sacloud/usacloud
- https://manual.sakura.ad.jp/api/cloud/portal/?api=simplemq-api
- https://github.com/sacloud/sakumock

Transcript

1. クラウドを使う側から、作る側へ 変わったこと、変わらなかったこと 2026-07-24 大吉祥寺.pm 2026 前夜祭 藤原俊一郎 (@fujiwara)
2. 自己紹介 @fujiwara (X, GitHub, Bluesky) @sfujiwara (hatena, mixi2) 2011〜2024 面白法人カヤック 2025-02〜 さくらインターネット ISUCON 優勝4回 / 運営(出題)4回 github.com/kayac/ecspresso github.com/fujiwara/lambroll
3. さくらインターネットでの仕事 所属: サービス統括本部 > サービス開発部 > クラウド制御基盤グループ 要するに「VMを立てたり落としたりするコントロールプレーン」を 開発、運用するチーム (AWSでいうとEC2の部分) クライアントから呼び出されるAPIサーバー(PHP) VMやdisk(ストレージ)を管理するdaemonやツール(Go, Perl) それらを動かすためのミドルウェアやOS、監視やログ収集基盤 (MySQL, RabbitMQ, Kafka, Elasticsearch...) 依存関係的に 「さくらのクラウド」のマネージドサービスは(ほぼ)使えない
4. 2025-05 モニタリングを改善する仕事 https://speakerdeck.com/fujiwara3/osc-hokkaido-2025
5. Prometheus → Mackerel にも同時に metrics を送るように OpenTelemetry Collector processors prometheus receiver scrape scrape scrape 管理サービス VM /metrics ストレージ管理サービス /metrics ネットワーク管理サービス /metrics Mackerel otlp exporter otlp endpoint
6. OpenTelemetry Collector をどう用意するか 公式の distribution を使うのが簡単だが… 公式の最小構成では欲しい機能が足りない 全部入りの contrib は何でもかんでも入っているので無駄に大きい 不要なコンポーネントによるセキュリティリスクなども → 必要なコンポーネントだけを組み合わせてビルドするのが推奨 https://opentelemetry.io/docs/collector/custom-collector/
7. OpenTelemetry Collector を自分でビルドする 公式に用意された ocb (OpenTelemetry Collector Builder) を使えば簡単 https://github.com/open-telemetry/opentelemetry-collector/tree/main/cmd/builder dist: name: sacloud-otel-collector description: OpenTelemetry custom collector for sacloud output_path: ./src exporters: - gomod: go.opentelemetry.io/collector/exporter/debugexporter v0.125.0 - gomod: go.opentelemetry.io/collector/exporter/otlpexporter v0.125.0 - gomod: github.com/open-telemetry/opentelemetry-collector-contrib/exporter/prometheusremotewriteexporter v0.125.0 - gomod: go.opentelemetry.io/collector/exporter/otlphttpexporter v0.125.0 - gomod: github.com/open-telemetry/opentelemetry-collector-contrib/exporter/fileexporter v0.125.0 processors: - gomod: go.opentelemetry.io/collector/processor/batchprocessor v0.125.0 - gomod: go.opentelemetry.io/collector/processor/memorylimiterprocessor v0.125.0 - gomod: github.com/open-telemetry/opentelemetry-collector-contrib/processor/resourceprocessor v0.125.0 - gomod: github.com/open-telemetry/opentelemetry-collector-contrib/processor/attributesprocessor v0.125.0 - gomod: github.com/open-telemetry/opentelemetry-collector-contrib/processor/transformprocessor v0.125.0 receivers: - gomod: go.opentelemetry.io/collector/receiver/otlpreceiver v0.125.0 - gomod: github.com/open-telemetry/opentelemetry-collector-contrib/receiver/prometheusreceiver v0.125.0 - gomod: github.com/open-telemetry/opentelemetry-collector-contrib/receiver/hostmetricsreceiver v0.125.0 - gomod: github.com/open-telemetry/opentelemetry-collector-contrib/receiver/jaegerreceiver v0.125.0
8. 2025-05 sacloud-otel-collector 誕生(社内repo) ちょうどその頃、クラウド制御基盤以外のチームでも需要があったので 「用意しました！足りないコンポーネントがあれば言ってください！」 「自前でビルドしたほうが…?」と迷っていたチームもあったが 「これ追加できます?」「できました！」を即日対応していたら使われるようになった 注: 何でも無闇に足していたわけではない 追加したいコンポーネントの素性を調べる → YAMLとREADMEに追加するPR だけで対応できるので手間ではない
9. ところで2025年に忙しかったやつ: ガバメントクラウド対応
10. https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/d6b5753c-c4eb-4ee6-92d021b3fa945a82/8bcd22f0/20260327_policies_gov_cloud_outline_01.pdf
11. ガバクラ = 政府自治体システムの共通クラウド基盤 https://speakerdeck.com/kazeburo/sakura-techday-develop-govcloud-and-the-team?slide=7
12. 別紙2: 技術要件詳細「サービス要件（基本）」 項 番 項目 要件 モニタ コンピュートやRDB等インスタンスベースのサービスについては、インスタンスごとの 107 リング CPU使用率、メモリのページング、ディスク容量（使用率）、ストレージのIOPS、スルー 機能 プット、ネットワークトラフィック量を監視、可視化できること 従来はVM外から観測できる CPU, Network, DiskIO のみ提供 メモリやディスク容量の監視にはVM内のagentが必要
13. モニタリングスイート(マネージドサービス)はある https://knowledge.sakura.ad.jp/49327/
14. 設定例がログ(fluent-bit)/メトリクス(prometheus)/トレース(otel) でバラバラ… [OUTPUT] Name Match Host Port Tls Logs_URI Header opentelemetry * ****.logs.monitoring.global.api.sacloud.jp 443 On /v1/logs Authorization Bearer log-****************** remote_write: - url: "https://****.metrics.monitoring.global.api.sacloud.jp/prometheus/api/v1/write" authorization: credentials: met-*********** receivers: otlp: protocols: http: grpc: processors: batch: timeout: 15s send_batch_size: 8092 send_batch_max_size: 16184 exporters: otlphttp/sakura-monitoring-suite: endpoint: https://****.traces.monitoring.global.api.sacloud.jp headers: Authorization: "Bearer trc-*********" service: pipelines: traces: receivers: [otlp] processors: [batch] exporters: [otlphttp/sakura-monitoring-suite]
15. お客様のVMで sacloud-otel-collector を動かせばいいのでは? otel collector なら要件で求められているメトリクスやログを取得 → モニタリングスイートに送信できる メトリクス hostmetrics receiver (VM内のメトリクスを取得) prometheusremotewrite exporter (モニタリングスイートへ送信) ログ filelog , journald receiver (VM内のログを取得) otlp exporter (モニタリングスイートへ送信) シングルバイナリでインストールも簡単
16. 2025-06 sacloud-otel-collector を github.com で公開 github.com/sacloud/sacloud-otel-collector 「これを入れれば項番107を満たせます」とした 項 番 項目 要件 モニタ コンピュートやRDB等インスタンスベースのサービスについては、インスタンスごとの 107 リング CPU使用率、メモリのページング、ディスク容量（使用率）、ストレージのIOPS、スルー 機能 プット、ネットワークトラフィック量を監視、可視化できること
17. 2026-01 モニタリングスイート専用 sacloud exporter 作成 exporters: sacloud: metrics: endpoint: "123456789012" token: met-****** logs: endpoint: "123456789012" token: log-****** traces: endpoint: "123456789012" token: trc-****** シンプルな設定 + 最適なバッファリング設定も自動 (サーバーが受け付けられないサイズで送信してしまうと100%ロストするので重要) 実は Mackerel Distro of OpenTelemetry (MDOT) Collector の真似
18. 比較: sacloud exporter を使わない場合 exporters: prometheusremotewrite/sakura-monitoring-suite-metrics: endpoint: https://123456789012.metrics.monitoring.global.api.sacloud.jp/prometheus/api/v1/write headers: Authorization: "Bearer met-****" resource_to_telemetry_conversion: enabled: true otlphttp/sakura-monitoring-suite-log: endpoint: https://123456789012.logs.monitoring.global.api.sacloud.jp headers: Authorization: "Bearer log-****" otlphttp/sakura-monitoring-suite-trace: endpoint: https://123456789012.traces.monitoring.global.api.sacloud.jp headers: Authorization: "Bearer trc-****" processors: batch: timeout: 15s send_batch_size: 8092 send_batch_max_size: 16184
19. 変わらなかったこと: 自分で使う→社内でも使う→他の人も使える sacloud-otel-collector は 最初からOSS化を意図して作ったわけではない 1. 自分のチームで使うために作った 2. 社内の他チームでも使ってもらうようになった 3. OSS化してお客様も使えるようになった 自分のために作ったもの → 一般化した形に昇華 ecspressoなどのOSSも全部同じ。最初は自分の仕事を片付けるためのもの 自分の仕事が片付かない道具に価値はない 価値がある道具なら、一般化して他の人も使えるようにすると嬉しい(こともある)
20. 2025-11 ある日のこと 他チームのマネージャー 「ちょっと助けてほしいんですが……」 「YAPCで忙しいので帰ってきたら話聞きますね！」 (2025-11-14, 15 YAPC::Fukuoka 2025)
21. 2025-11-18 YAPCから帰ってきたら 「もうすぐリリースの某サービスの本番とステージング環境がまだ何もできてない」 「えっ?」
22. 2025-11-18 YAPCから帰ってきたら 「もうすぐリリースの某サービスの本番とステージング環境がまだ何もできてない」 「えっ?」 「さくらのクラウド上で作ってほしい、開発環境用のTerraformはあります」 「なるほど? まあTerraformで構築できるなら1ヶ月あれば余裕で…」
23. 2025-11-18 YAPCから帰ってきたら 「もうすぐリリースの某サービスの本番とステージング環境がまだ何もできてない」 「えっ?」 「さくらのクラウド上で作ってほしい、開発環境用のTerraformはあります」 「なるほど? まあTerraformで構築できるなら1ヶ月あれば余裕で…」 「とある要件でDBアプライアンス(マネージドサービス)は使えないのでPostgreSQLの HA構成をVM3台で組んでほしくて、検証はまだしてないんだけど」 「ValkeyもマネージドサービスがないからVMで6台クラスタね」 「えっえっ?」 「あとデプロイの仕組みとDBバックアップとレストアと監視も………」
24. 本番環境構築RTA(約1ヶ月) 無事リリース完了
25. ところでこのサービスは SimpleMQ を多用している SimpleMQ: さくらのクラウドのキューのマネージドサービス (AWSでいうところのSQS) ガバクラ要件のため、IaC(Terraform provider)とSDK(Go)はOSSチームで用意してあるが CLIがなかった 項 番 項目 リソース作 115 成・管理機 能 要件 システムを稼働させる環境一式を自動的に作成し、管理するために、Infrastructure as Code(IaC)の機能が利用可能であること IaCでは、インフラストラクチャの構成をコードで管理し、冪等性を担保したイン フラストラクチャの構築や全く同一の環境を迅速に複数作成することが可能である こと
26. 2025-12 構築運用にCLIがないと不便すぎるので、作った GoのSDKはあるので難しくはない github.com/fujiwara/simplemq-cli SimpleMQ用のCLI 構築中のキュー操作や運用中のモニタリングに使う github.com/fujiwara/sakura-secrets-cli シークレットマネージャ用のCLI デプロイやプロビジョニングのために必要 とりあえず、これで仕事は進む usacloud (公式CLI) には多くの機能があるが 最近(ガバクラ対応で)追加されたサービスへの追従が追いついていない
27. CLIを作るにはテストが必要 テストは本物のサービス(API)でもできるがお金がかかる さくらのクラウドの料金体系は完全従量課金は少なく リソースあたり固定の時間単価が決まっているものが多い (料金の予測がしやすいというメリットがあり、好評でもある) 仕事の開発用アカウントは無料化されているが、CLIは個人開発 ( github.com/fujiwara 配下)なので個人アカウントでやっていた (Claudeを自由に使えるという面も…)
28. テストするためには: API の mock server を書けばよい 新しめのサービスはOpenAPI定義が公開されている SimpleMQの例 https://manual.sakura.ad.jp/api/cloud/portal/?api=simplemq-api → SDK実装とAPI定義を突き合わせれば、かなりそれっぽく作れる simplemq-cli, sakura-secrets-cli ともAPI mock serverをリポジトリ内に作成
29. 2026-03 API mock serverが3個ぐらい貯まったんだけど…… 「まとめたら LocalStack 的に使えるのでは？」 OSSチームと相談の上、誕生したのが公式の API mock server sakumock github.com/sacloud/sakumock
33. 変わらなかったこと: 自分のために作る→他の人も使える 1. 仕事に必要なCLIがなかったので作った 2. (その一部が) 公式のOSSになった いつもと同じ。自分の仕事を片付けるために作る それが有用なら他の人の役に立つように昇華できる (公式CLIもリニューアル企画中)
34. 変わったこと クラウドの「利用者」だったのが「中の人」になって変わったこともある 公式を自分で改善できるようになった 今までは「公式が不便だから作った」ものも結構ある 公式が便利ならそれが一番良いのでは？ ただし「便利」は人それぞれなのでいろんなOSSがあるのは良いこと 利用者の幅が広がった Windows Server 環境とか 自分が今まで運用していない環境もある程度意識して作る必要がある クラウドの中の人も(ある程度)自分のクラウドの利用者 利用者としての経験が、提供者として役に立つことも多い
36. 最後に一句 みずからを 助くるものを オープンに