開発者を「顧客」として捉え、生産性を向上させるPlatform Engineering
リリースと改善を高頻度で回す最近のITシステム開発。何かあってもすぐに修正できることで、品質と安定性を担保することへの精神的負担から少し解放され、場合によっては評価にもつながったハッピーな開発者も少なくないだろう。一方で、運用周りを考える必要が生じるなど責任範囲が広がり、ツールやスキルで習得すべきものも増加。開発そのものに集中しづらく、いろいろなことをカバーする必要があることからスーパーマン以外が活躍しづらいという課題も浮上している。
そこで登場したのが、Internal Developer Platform（IDP）だ。IDPは、開発者を「顧客」として捉え、開発により集中できる環境を整えることを目的とした基盤のことだ。IDPを運用開発するのは、専任チームだ。開発に関わる基本的な作業を自動化やセルフサービス化するなどにより、開発者が抱えるリアルな課題を解決する。一見するとユーザーとパブリッククラウドの関係のように見えるが、組織ごとの課題や要件に合わせて環境をカスタマイズできる点で大きく異なると、ヤフーのプライベートクラウド開発部門でKubernetesベースのコンピューティングプラットフォームの開発・運用に従事する早川博氏は述べる。
そのIDPを実現するための要素技術として重要な役割を担うのが、多様性のあるエコシステムが構築されたクラウドネイティブなテクノロジー群だ。特にKubernetesは、さまざまなワークロードを安定的に動かすための基本機能が充実するほか、組織固有の要件を実装するための拡張ポイントが多数用意されており、開発者が使い勝手に慣れている点も含めてIDP構築に最適と早川氏は述べる。実際、ヤフーではKubernetesの拡張ポイントのひとつであるカスタムコントローラーを使ってIDPを構築している。
高い開発者体験を実現する開発環境の仕組み
Kubernetesには、何かを実行するとそれに連動して必要な操作が自動実行される「コントローラーパターン」と呼ばれる仕組みがある。その実行部分を担うのが、Kubernetesクラスター内で動作するコントローラー群だ。
早川氏は、それぞれの役割を図で説明した。たとえばユーザーがデプロイを実行すると、データストア（etcd）にデプロイメントリソースが保存される。これを受けて、コントローラー群のひとつであるDeployment ControllerはReplicaSetリソースを作成、データストアに保存。それを検知したReplicaSet ControllerがPodを新規作成。さらにそれを検知したkube-schedulerがPodの配置先を決定して、Podが起動する。Kubernetesには、状態を観測しながら指定の状態になるようプロセスを繰り返すReconciliation Loopというロジックがあり、これらがうまく連係することで自動実行の仕掛けが完成する。
Kubernetesにはさまざまなリソースが標準で用意されているが、すべてのユーザーのニーズに一致するものが揃っているわけではない。そこで登場するのが、CRD（Custom Resource Definitions）とカスタムコントローラーだ。カスタムリソースをCRDで定義し、その状態をチェックして指定の操作を実行するカスタムコントローラーを実装することにより、Kubernetesの機能を拡張できるというわけだ。
ヤフーのカスタムコントローラー活用事例
ヤフーではこのカスタムコントローラーを活用して、同社固有の要件に応える、高い開発者体験を実現するKubernetesベースのアプリケーション実行環境を構築している。早川氏は同社の開発環境の特徴を3つ紹介した。
- セルフサービスで利用開始
- アプリケーション実行までの手間の簡素化
- マルチテナント＆スケーラブル
1つめは、開発者がセルフサービスで利用開始できる点だ。開発者はブラウザ画面でNamespaceを作成すれば、アクセス権が自動設定され、自分の所属するチームのみが使えるNamespaceをすぐに利用可能になる。具体的には、Namespaceを作成するとAPIが呼び出され、Git管理されているマニフェストのレポジトリにNamespaceが作成され、CIツールからクラスターに反映される。そして、それを検知したカスタムコントローラーが権限管理システム（Athenz）に権限情報を登録、権限制御が働くようになる。Namespaceで別チームやプロジェクトの情報を取得しようとしても、Forbiddenが返ってくる。
2つめは、デプロイに関する手間の簡素化だ。簡単なコマンドまたはカスタムリソースからアプリケーションをデプロイするとカスタムコントローラーが発動し、DNSサーバーにレコードを登録。エンドポイントにURLを自動的に払い出すという仕組みだ。そして3つめは、マルチテナントとスケーラビリティの実現だ。同社では、1つのメタクラスターが複数のKubernetesクラスターを束ねる、超大規模なアプリケーション実行基盤を構築している。メタクラスターはアプリケーションのデプロイ指示を受けると、適切なクラスター上でアプリケーションを起動する。ユーザーはクラスターを意識することなく、アプリケーションにアクセスできる。
このほか、アプリケーションIDの自動設定も提供している。アプリケーションがデプロイされると、アプリケーションを一意に識別可能なクライアント証明書がPodに自動設定され、それに対応するアプリケーションアカウントがカスタムコントローラーによってAthenz上に登録される。KubernetesのSecretを管理しなくても外部システムにアクセスするための認証情報を自動的に設定できると早川氏は説明する。
カスタムコントローラーの開発で注意すべきポイントは？
より使いやすい開発環境の実現に有効なカスタムコントローラーだが、実際にどう開発すればいいのか。早川氏は、同社で実践している開発の流れを紹介した。
大まかな流れは、設計、コントローラーの実装およびテスト、リリースの3段階だ。設計で試行錯誤してからひとつずつ実装、テスト、リリースして、設計にフィードバックするサイクルを回していると早川氏は言う。
設計では、主に次の3つを行っているという。
- コントローラーとカスタムリソースの構成を決める
- カスタムリソースの仕様を決める
- コントローラーごとに詳しい挙動を整理
1つは、作りたい機能を実現できるよう、コントローラーとカスタムリソースをどのような単位で作るか、さまざまなパターンを図で書き出して考える。「1つのコントローラーに機能を詰め込みすぎると、メンテナンスが大変になったり挙動が不安定になったりするので、その点を意識して試行錯誤している」（早川氏）
2つめは、どのような情報をカスタムリソースで記述するのかなど、manifestを書きながらカスタムリソースの仕様を考える。そして3つめは、コントローラーそれぞれの挙動を詳細に書き出して整理する。たとえば前述の権限設定するカスタムコントローラーの場合は、Namespaceリソースが新規作成されたというイベントに対して、AthenzPolicyClaimリソースをこのような値で作成するといったように、イベントごとの動作をリストアップするのだ。「この情報はそのままテストケースとしても使える」（早川氏）
コントローラーの仕様を決めるときのポイントとして、挙動を多く設定しすぎるとコントローラーの役割が増えすぎて、テストを書くのが大変になると指摘。増えすぎるようであれば、挙動を複数のコントローラーに分けるといった工夫をしたいと述べた。
設計が確定したら、次はコントローラーの実装だ。ここでのポイントは、コントローラーを1つずつ実装することだ。「きちんと設計されていれば、コントローラーの挙動は互いに独立しており、自分の担当するReconciliation Loopを回すだけで良い状態になっているはずだ」（早川氏）
コントローラー単位で開発すると、スクラム開発にうまくはまるというメリットもあると早川氏は明かす。「意味のある小さな単位でリリースし、早めにフィードバックを得て改善するという流れが作りやすく、複数チームでの分担もしやすい。スプリント単位でコントローラー作成するのがお勧めだ」。
同社では、さまざまな場所でアプリケーション実行基盤についての発表を積極的に展開している。気になる人はぜひチェックしてほしいと早川氏は述べて、講演を終えた。
