はじめに

KADOKAWA Connected KCS 部の nokamoto です。 KCS 部では KADOKAWA グループ向けプライベートクラウドを提供していますが、今回は KCS 全般の課題とそれを解決するために進めているプロジェクトについて投稿します。

課題：インターフェースの再開発

KCS は複数のチームが提供しているサービスの集合です。例えば、仮想マシンを扱うサービスと MySQL を扱うサービスはそれぞれのチームが開発運用しています。

サービスを開発するチームが異なるために、インターフェースもばらばらに開発されています。結果としてサービス毎に似たような機能が再開発されています。

f:id:kdx_writer:20210319103918j:plain:h500

この再開発にはいくつか問題があります。

一つ目は、単純に再開発のコストの問題です。サービスを追加するたびにインターフェースの問題を解決するための開発コストや運用コストを払う必要があります。

二つ目は、利用者の学習コストの問題です。個々のサービスがばらばらのインターフェースを設計したことで、サービスの提供方法もばらばらになりました。例えば、あるサービスを利用するためにはそのサービスが運用する Web コンソールから、あるサービスを利用するためにはそのサービスが運用する Jenkins から、というように不揃いなインターフェースは利用者にそれぞれの学習を要求します。

三つ目は、サービス間の連携です。 KCS のサービス提供に必要とされる利用者の情報にはサービス間で大きな差がありません。

利用者の識別子
利用者のコスト配賦先
利用者の連絡先

基本的に上の三つの情報を前提とする設計をしていて、かつそれらの情報を個別に収集して管理しています。この問題は、KCS のサービス間の連携を困難し、利用者の利便性も損なっています。

KCS のサービス間の連携を困難とする例を上げると、利用者の識別子が個々のサービスで微妙に異なっていることがあります。

f:id:kdx_writer:20210319104115j:plain:h500

個々のサービスの設計により識別子に許容される文字がハイフンであったりアンダースコアだったりするため、同じ利用者を指している場合でも異なる識別子で管理されているケースが多くあります。サービスが利用者の認識の仕方を互いに共有できていないため、連携することも困難です。

利用者の利便性を損なう例をあげると、利用者が情報を修正しようとする場合に利用する全てのサービスで修正操作を要求されるということがあります。現実的には、そのような煩雑なインターフェースが受け入れられることはないと考えられるため、現状情報の管理が正しく行われているかは疑問です。

これらの問題を解決するためには KCS は横断的なインターフェースを提供する必要があります。

課題：自動化

KCS のインターフェースにはチケットによる申請が残されていて、その裏ではサービス提供者による手動の運用作業があります。手動の運用作業はリードタイムを発生させることで利用者のアジリティを損ないます。基本的に手動の運用が入るとリードタイムは良くて数営業日以内程度になっています。

KCS では既にこの問題を解決するためにオンデマンドなセルフサービスを実現している例もあります。しかし、それらは全て各チームの努力で実現したもので、別のチームで再現するためには再開発が必要です。

自動化を KCS 全体の課題として取り組まないと、個々のサービスの自動化にも障壁が発生します。なぜなら個々のサービスの自動化には依存する他サービスのリソース操作の自動化が要求される場合があるからです。

例えば、Kubernetes クラスタの作成には VM の作成とロードバランサーで Kubernetes API を公開する必要があります。

f:id:kdx_writer:20210319104448j:plain:h500

この場合、KCS では VM の作成はある程度の自動化が出来ますが、ロードバランサーの設定変更は申請ベースで行われているため、何らかのワークアラウンドが要求されます。

これらの問題を解決するために KCS 全体として自動化という課題に取り組む必要があります。

KCS Interface プロジェクト

これらの KCS のインターフェースに関する問題を解決するために KCS Interface という横断的なプロジェクトを立ち上げました。

自動化に重要なのは API です。このプロジェクトでは各サービスに API を提供してもらうことを目的の一つとしています。

API が出来た次に必要なのは横断的なユーザーインターフェースです。各 KCS サービスの責務は API の提供までと決め、その先は KCS Interface のプロジェクトで新たに立ち上げた CLI やコンソールのサービスの責務とします。

KCS Interface で整理された後の全体像を示します。

f:id:kdx_writer:20210319104943j:plain:h500

今まで各サービスは VM 等の固有のリソースを管理していました。それに加えて固有のユーザーインターフェースを提供していましたが、KCS Interface で整理された後は代わりに標準化された API を提供してもらいます。また、各サービスチームに API の開発に注力してもらうために、KCS Interface では API を提供するために必要な標準化に取り組みます。

標準化の例に CI/CD があります。 API 開発者がアプリケーションに注力できるように、KCS Interface では Argo CD を採用してコードをリポジトリに入れるだけでデプロイ実行まで自動的に行われる仕組みを提供します。

別の例として認証認可の標準化があります。これまで各サービスで似たような仕組みを再開発していた処理は Gateway 部分で解決するようにします。ここでは以前の投稿で紹介した Envoy の仕組みを利用したりしています。

次に横断的なユーザーインターフェースを考えます。サービスに API を提供してもらうことで、複数のサービスを API 経由で操作するクライアントが作成できるようになります。

f:id:kdx_writer:20210319112423j:plain:h500