Cloud Native Days Summer 2024

クラウドネイティブな省エネサービスの内製開発で、BizDevOpsを実現する

北海道ガスの方の発表

BizDevOps
マイクロサービスアーキテクチャ
- 拡張性の観点で選択
- 当初から何を手を付けていくかわからなかった。
開発環境の構築
- オンボーディングを簡単に
- Write and modify code with Dev Environments in CodeCatalyst - Amazon CodeCatalyst
- 簡単にボタンひとつでhelmやDockerを導入できる環境がつくれる。

リードタイム、コストを最適化しながら回復性を求めるクラウドネイティブ戦略

エゾウィンのCTOの方の発表

レポソク
- 農業車両の位置情報を管理するアプリケーション
回復性
- タイマーのしきい値の設定方法
- 通信できない場合にはエッジの端末でバッファリング
サーバレス
- AWS SAMを使っている。
サーバレス以外
- AWS CDKでリソースを管理
Obsevability
- AWSのManaged Servicesを使う
- X-RayとCloudWatch(logs, metrics)を利用

次世代のクラウドネイティブ基盤、Wasmの今と未来

未踏クリエイタの方々の発表

CNDS2024 - Speaker Deck

Wasmのメリット
- フットプリントが軽い
- マルチCPUアーキテクチャに単一バイナリで対応しておりポータビリティが高い
- セキュリティ
Wasmのレジストリ
- WebAssembly Components
- 現状では確立しきれていない。
課題
- モジュール同士の呼び出し
  - Component Model
    - WIT
    - Canonical ABI
Wasmを実行可能なcontainerd-shimの実装
- containerd/runwasi: Facilitates running Wasm / WASI workloads managed by containerd
MicroVM(e.g. Firecracker)やコンテナとの立ち位置
- Will “WebAssembly” be the next generation of Java and Node.js? –Running “Wasm Container” with Kubernetes | NTT DATA Group
- 上記の資料をみると4種類のデプロイメントのパターンがあるそう。
- OCIランタイムのレイヤやコンテナランタイムのレイヤにWasmランタイムどう入れ替えていくかの方針は気になる。

OpenFeature と自動生成を活用した、フューチャフラグの宣言的集約管理

CyberAgentの方の発表

OpenFeatureと自動生成を活用したフューチャーフラグの宣言的集約管理 - Speaker Deck

トランクベース開発
- ブランチのサイクルを短くする
- メインブランチにすぐMergeしやすくConflictが防ぎやすい
Feature Flagの分類
- “static vs dynamic toggles”
- Feature Toggles (aka Feature Flags)
課題
- ベンダー/プロバイダによってSDKの実装に違いがある。
- ベンダーロックインが発生する。
解決策:OpenFeature
- CNCFのIncubating Probjectに採択
- Feature Flag管理のオープン標準規格
- Dynatraceが主導している。
- メリット
  - ベンダーロックインを避けられる。
  - ベンダーを変えるときにProviderを変えればよい。
課題
- Feature Flag管理のSaaSで開発する際には、Web ConsoleでFlagを発行してソースコードに埋め込む。
- Flagの管理をコードベースで管理したい。
- Terraformを使うとソースコードとTerraformマニフェストが分離され管理しにくい。
解決策:自動生成で宣言的に管理
- ProtoファイルにTerraformに必要なメタデータを定義しておく。
- ProtoファイルからTerraformマニフェストを動的に生成する。
- OpenFeatureを組み合わせるとベンダーの切り替えもしやすい。
- フラグの有効期限をつけて、それをチェックするテストを作成し、古いFeature Flagのコードが残り続けることを防ぐ。
課題
- 削除ライフサイクルの課題がある。
- Feature Flag Service as a Service
- Gitリポジトリのブランチごとにフラグの削除の有無に差分が生じる。
解決策(検討中)
- git diffを使って差分をもとめて出来るのではないか。
- Freeeの事例: GoのASTを解析してFeature Toggleを掃除する - freee Developers Hub

テレメトリーシグナルの相関、してますか？第一原理からのデバッグを支える計装

著書(翻訳/監訳)の1つにObsevability Engineering
- Honeycomb’s O’Reilly Book Observability Engineering
推測だらけのデバッグ
- 過去の経験をもとにした断片的な情報だけでの推測にもとづいてデバッグする。
- 推測なしの演繹: 具体的なメトリクスに基づく判断
事象を計測するためのテレメトリシグナル
- ログ
  - イベントドリブン, 時系列変化
- トレース(特殊なログ)
  - イベントドリブン, 時系列変化
- メトリクス(何らかの統計処理がされている)
  - 統計, 時系列変化
- プロファイル
  - 統計
テレメトリ同士の関係
- トレースのIDをログにいれると追跡しやすい。
- トレースのIDをメトリクスに埋め込むと追跡しやすい。
- 特定のメトリクス変化から代表的なトレースやログを選ぶ。
- ログからメトリクスの計算(例:条件でフィルタして行数を計算)はよく見かける。
システムのサイロ化
- たまに見る構成
  - Logs: Elasticsearch
  - Metrics: Prometheus
  - Traces: Jaeger
- 理想はLogs, Metrics, Tracesを連携できる必要がある。
- クラウドプロバイダの製品は連携できる機能が用意されている。
- OSSならLGTM(Loki, Grafana, Tempo, Mimir) Stackがある。

マイクロサービス基盤にフルマネージドサービスではなくKubernetesを選択する理由

マイクロサービス基盤にフルマネージドサービスではなくKubernetesを選択する理由 - Speaker Deck

2022年よりも前はkOpsを使ってKuberentesクラスタを管理していた。
自前で構築するKubernetesは保守が大変になる。
2014年からKuberentesを本番での運用に使っていた。
2014年当時はフルマネージドサービス(ECS, Cloud Run)の機能性が悪かった。
2024年はフルマネージドサービスが2020年よりも使いやすくなってきた。
2024年にKubernetesを使う優位性はあるか。
Wantedlyでマイクロサービス基盤の要件
- マイクロサービスの運用ができる
- マイクロサービスの開発ができる
重視すべき観点
- 変更を素早く試せる
- 他の変更の影響を受けない。
- 依存するサービスを意識しなくてよい。
開発環境(デバッグ)
- ローカル環境
- 共有のリモート環境
- 開発者ごとのリモート環境
  - 課題:理想ではあるがコストが高い
  - 解決策:kubefork
kubefork
- マイクロサービス同士でリクエストヘッダを使ってIstioでルーティングを制御
- 個人のマシンはTelepresenceを使って接続
- 足りない機能はカスタムコントローラを使っている。
- Kubernetesのエコシステムを利用するとカスタマイズがしやすい。
- フルマネージドサービス(ECS, Clooud Run)ではカスタムコントローラが使えない。
課題:Kubernetesのコスト
- 学習コストが高い
- メンテナンスコストが高い(リリース頻度の高さ)
解決策
- 責務をクラウドに切り出す
  - kOpsからEKSへ移行
  - クラウドサービスのテクニカルサポートが使える
- 運用フローの改善
  - 内製ツール kube の開発
  - 学習コストの改善
  - 過去に使っていたツールとの親和性を維持
- cluster addonの管理
  - 処理とマニフェストの一致(cluster addon = container image + k8s manifest)
  - cluster addonの更新で消されない不要なリソースの削除
  - 取り組み
    - helmfileでcontainer imageとk8s manifestを管理
    - ドキュメント化
      - 作業を資料に残す
      - アップグレード作業を振り返る
- キャパシティを増やす
  - 人材の採用
  - 経営陣への説明