300人から1000人へ――メルカリは開発組織を拡大するため「マイクロサービスアーキテクチャ」を採用した(前編):Mercari Tech Conf 2018(5/5 ページ)
現在300人程度という開発者の数を3倍以上の1000人に増やそうとしているメルカリ。そのために同社はマイクロサービスアーキテクチャを採用し始めました。このシステムをうまく機能させるため、技術面と組織面の双方でさまざまな取り組みを行っています。
Kubernetesを名前空間でチームごとに切り分け
最後は、開発者のインフラへのアクセス制御の整備です。
以前は、インフラに触れるのは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」を許可を得た上で転載、編集しています。
関連記事
- 変化に強いシステムを目指し、マイクロサービス、サーバレス、内製化に挑戦 最先端技術に挑むダイソーの情シスたち
市場環境の変化が速い小売業界で勝ち残るためには、システムも変化に柔軟に対応できるものでなければならない。ならばマイクロサービス、サーバレス、内製化に挑戦しよう――。そんな大創産業の情シス課長、丸本健二郎氏の挑戦を追った。 - コレ1枚で分かる「マイクロサービス」
Eコマース企業やオンラインサービス企業などに採用され、注目を集めているソフトウェアアーキテクチャ「マイクロサービス(Microservices)」について、特徴とメリットを解説します。 - SREって、具体的にどんな仕事する人たちなの?
インフラ構築や運用に必要なコストが変わってきている昨今、運用技術者に求められる役割が変わりつつあります。それが「SRE」です。日本ではまだまだ一般的ではない概念ですが、本連載ではリクルートグループの例を通じて、その実態をお伝えしていきます。
関連リンク
Copyright © ITmedia, Inc. All Rights Reserved.