非線形に増加するトイルをKubernetes Operatorで解消しビジネス拡張を支えた by イスキエルド　ダニエル

■ 発表カテゴリ

・Tech: SREを支える具体的な技術や手法

■ 発表概要（400字程度）

2つの異なるブロックチェーン間で情報を中継するサービスをSREとして運用する中で、作業のスケーリング問題に直面しました。

サービス内部の専門知識があるエンジニアであっても、各インスタンスのデプロイには、1〜2人日を要する手作業が伴っていました。各サービスインスタンスは、単一のブロックチェーンペアを処理します。これは、N個のブロックチェーンを扱うには「N個の中から2個を選ぶ」組み合わせの数（例：5個なら10、10個なら45）のインスタンスとその関連作業が必要になります。より多くのブロックチェーンに対応する事業計画があったため、この手作業を続けるわけにはいかないと分かってきました。

そこで、Kubernetesのオペレーターパターンを利用し、サービスを宣言的に定義することで、環境構築の完全な自動化とデプロイに必要な知識の軽減を達成しました。マニフェストを作成して適用することで、今では１時間程度で作業が完了できるようになりました。さらに、サービスステータスの可視性も向上しました。

しかし、社内にはこれまでオペレーターの開発経験がありませんでした。Kubernetesをそのまま利用するSREとして、APIやコントローラーの動作はある程度理解していましたが、深く掘り下げた経験はありませんでした。このような内部構造に踏み込み、多くの知見を得ることができました。

本発表では導入事例として、オペレーターパターンを選択した経緯、開発で学んだ点や注意すべきポイント、公式ドキュメントだけで分かりにくい実践的な知見、そして導入後の成果を共有させていただきます。

■ 発表の詳細（1000字程度）

ユーザーにサービスを提供するためにRelayerという、異なるブロックチェーン間のパケット通信を支えるシステムを運用しています。弊社R&Dチームで開発されており、私達SREチームはRelayerの運用責務があります。

新しい環境（過去にデプロイされたことのない環境）に導入する際には、まずhandshakeという処理を行う必要があります。これまでhandshakeは複数のシェルスクリプトで実装されており、各スクリプトの間に手動で正確にアウトプットを整理する必要がありました。また、各スクリプトの実行には数時間かかる場合が多く、大きな手間となっていました。

Relayerの特性とビジネス計画を踏まえ、環境が爆発的に増加すると想定しました。この状況から、今後も手動で対応し続けることは不可能だと判断しました。そして、CIで一時的な環境を自動構築したいという要望も強まってきました。SREの重要なミッションである「自動化」と「トイル削減」の観点から、Relayerのデプロイは高優先度で自動化の対象となりました。

cert-managerやPrometheus Operatorといった、広く利用されているオペレーターの存在は知っていました。これらの例から、Kubernetesの動作を変更できるという知識はありましたが、Relayer関連の自動化にまさに適しているのではないかと思い至りました。もちろんIaCで環境を構築したり、既存のシェルスクリプトを向上させたり、オペレーターパターン以外の選択肢も検討しました。オペレーターを開発するのは一番適切な選択肢だと考えましたのでそれについて発表で詳しく説明します。主に、Operator Whitepaperが述べる３つの特性（宣言的な設定、Kubernetesネイティブな動作、ドメイン固有の知識のカプセル化）がこの課題解決に一致しています。

オペレーター開発をするためにはKubernetesの内部動作を深く掘り下げる必要がありました。Kubernetes API を介してリソースが作成されたとき、そのリソースのデフォルト値はどのように、そしていつ設定されるのか？コントローラーはどのように実装されているのか？不要になったリソースは誰がどのタイミングで削除するのか？

コントローラーの実装者は、予期せぬ挙動にも注意を払う必要があります。Kubernetes環境では、複数のシステムがネットワーク上で並行して動作し、共有された状態を変更します。これは、クリティカルなインフラストラクチャに影響を及ぼす可能性のある競合状態が発生しやすい状況です。このリスクは、プロジェクトをより困難なものにしました。

Relayerサービスに特有の考慮事項もあります。例えば、handshakeは実行するたびに少額の金銭的コストが発生します。そのため、リトライの暴走による予期せぬ高額なコスト発生の可能性を考慮する必要がありました。つまり、このオペレーターの設計にどのように取り組むべきかを十分に理解するために、ドメインエキスパートと時間をかけて話し合う必要がありました。

本発表を通じてこの経験を共有することで、特定の課題に対する解決策としてオペレーターパターンの選択肢を広げ、私たちが直面した問題を他のエンジニアが回避できるよう手助けしたいと考えています。

■ 対象聴衆とその人たちが得られるもの

対象聴衆: Kubernetesでサービス運用を行っているSREや開発者（中級者以上）と、Kubernetesクラスターそのものを管理している方。

得られるもの:

• オペレーターパターン導入の判断基準と適用シーン
• 開発時に注意すべき技術的ポイント
• 既存ツールとの比較検討プロセス
• 実装における具体的なベストプラクティス
• チーム内での技術習得と知識共有の方法

■ なぜこのトピックについて話したいのか（モチベーション）

Kubernetesのオペレーターパターンは、業界全体で利用が拡大しています。Operator Frameworkは2020年にCNCFプロジェクトとして組み込まれ、2021年にはOperator White Paperが発行されました。最近のトレンドとしては、AIに特化したオペレーターの作成や、データベース関連のオペレーターの継続的な開発が見られます。したがって、これは現在の SREチームにとって非常に興味深く、関連性の高いトピックだと考えています。

今回の経験で、オペレーターパターンを利用することによって自動化やセルフサービス性の向上を達成することができます。自分にも大変勉強になりましたし、ゼロからスタートの開発事例として共有するという貢献をしたいです。この発表によって、多くの方がオペレーター開発を試みていただければ嬉しいです。