最後は、開発者のインフラへのアクセス制御の整備です。
以前は、インフラに触れるのはSREチームだけだったため、インフラへのアクセス制御はすごくシンプルでした。しかし、マイクロサービスでは、各チームが自分たちのサービスを自分たちで管理運用するようになります。つまり、各チームが自分たちで管理しているサービスのインフラも自由に触れるようになる必要があります。そのためのアクセス権限の設計を行いました。
まず、いちばんの基礎となるKubernetesは、マイクロサービスプラットフォームチームがクラスタアドミンとして安定運用に責任を持ちます。そのため、マイクロサービスの開発者はKubernetesクラスタそのものへのアクセス権限は持っていません。
例えば、サービスAのチームが新たなマイクロサービスをリリースしたいというときは、まず、サービスA専用のネームスペース(名前空間)をKubernetes上に作ります。これはKubernetesの機能で、仮想的にクラスタを分離する機能です。Kubernetesクラスタの中にサービスA専用の部屋を作るようなイメージです。
そして、KubernetesのRBAC(Role-based access control)を使って、サービスAの開発チームをそのネームスペースの管理者として登録します。この部屋の鍵を渡すようなイメージですね。
これでサービスAの開発チームは、このネームスペースに自由にアクセスできるようになります。ここにデプロイしたコンテナに何か問題が起きたときには、コンテナのログを見たり、再起動したりするなどのオペレーションを自分たちで行えます。
サービスAの開発チームがGCPのCloud Spanner(グローバルに分散したRDB)などを使いたいときは、サービスA専用のGCPプロジェクトを作って、サービスAチームをその管理者に登録することで、自身のプロジェクトとしてGCPのサービスをそこに登録して、使うことができます。サービスBの開発チームが新たなサービスを作りたいときも、同様のことを行います。(後編に続く)
この記事は、新野淳一氏のブログ「Publickey」の記事「メルカリは開発組織を拡大するためにマイクロサービスアーキテクチャを採用した(前編)。Mercari Tech Conf 2018」を許可を得た上で転載、編集しています。
Copyright © ITmedia, Inc. All Rights Reserved.