300人から1000人へ――メルカリは開発組織を拡大するため「マイクロサービスアーキテクチャ」を採用した（前編）：Mercari Tech Conf 2018（5/5 ページ）

[新野淳一，Publickey]

Kubernetesを名前空間でチームごとに切り分け

　最後は、開発者のインフラへのアクセス制御の整備です。

　以前は、インフラに触れるのはSREチームだけだったため、インフラへのアクセス制御はすごくシンプルでした。しかし、マイクロサービスでは、各チームが自分たちのサービスを自分たちで管理運用するようになります。つまり、各チームが自分たちで管理しているサービスのインフラも自由に触れるようになる必要があります。そのためのアクセス権限の設計を行いました。

　まず、いちばんの基礎となるKubernetesは、マイクロサービスプラットフォームチームがクラスタアドミンとして安定運用に責任を持ちます。そのため、マイクロサービスの開発者はKubernetesクラスタそのものへのアクセス権限は持っていません。

　例えば、サービスAのチームが新たなマイクロサービスをリリースしたいというときは、まず、サービスA専用のネームスペース（名前空間）をKubernetes上に作ります。これはKubernetesの機能で、仮想的にクラスタを分離する機能です。Kubernetesクラスタの中にサービスA専用の部屋を作るようなイメージです。

　そして、KubernetesのRBAC（Role-based access control）を使って、サービスAの開発チームをそのネームスペースの管理者として登録します。この部屋の鍵を渡すようなイメージですね。

Kubernetes上にネームスペースを作ることで、各サービスチームがインフラへアクセスすることを可能にしている

　これでサービスAの開発チームは、このネームスペースに自由にアクセスできるようになります。ここにデプロイしたコンテナに何か問題が起きたときには、コンテナのログを見たり、再起動したりするなどのオペレーションを自分たちで行えます。

　サービスAの開発チームがGCPのCloud Spanner（グローバルに分散したRDB）などを使いたいときは、サービスA専用のGCPプロジェクトを作って、サービスAチームをその管理者に登録することで、自身のプロジェクトとしてGCPのサービスをそこに登録して、使うことができます。サービスBの開発チームが新たなサービスを作りたいときも、同様のことを行います。（後編に続く）

　この記事は、新野淳一氏のブログ「Publickey」の記事「メルカリは開発組織を拡大するためにマイクロサービスアーキテクチャを採用した（前編）。Mercari Tech Conf 2018」を許可を得た上で転載、編集しています。