ニュース
» 2018年10月12日 08時00分 公開

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

[新野淳一,Publickey]
前のページへ 1|2|3|4       

マイクロサービスプラットフォームチームがこれから取り組もうとしていること

 最後に、今後われわれが取り組んでいきたいことをご紹介します。先ほどお話ししたように、現在本番環境で動いているマイクロサービスの数が19であるのに対して、開発中のマイクロサービスは73もあります。

 マイクロサービスの開発を始める環境はできてきた一方、これからは本番環境に出て行くマイクロサービスが増えてきます。すると次の課題は、マイクロサービスの開発者が、自分たちのサービスをいかに高い信頼性を持つサービスとして運用できるようになるかです。

 これに対して、現在いくつかアイデアがあります。1つ目のアイデアは、GoogleのSREが採用しているSLI/SLOという指標を導入することです。SLI(Service-Level Indicator)はサービスレベルの定量的な指標、SLOはService-Level Objectiveの略でSLIに対する目標値です。これらはサービスの特性に合わせて決定できます。

 例えば、レスポンスを速く返すことが重要なサービスであれば、SLIは全てのリクエストのうち、100ミリ秒以内にレスポンスを返した割合で計る、といったものです。SLIとSLOを設定することで、数字に基づいて、サービスの機能開発と信頼性に対する取り組みのバランスをとることができるようになります。

 SLOを99.9%に設定した場合、これを満たしているうちはひたすら機能開発を続ける。これを下回ってしまったら機能開発を止めて、信頼性の向上に努めるといった方針転換がすぐにできます。これにより、機能開発ばかり進めて、障害がひんぱんにおきるサービスをなくしたり、逆に信頼性ばかり追求して、機能追加が進まなかったり、といった状況を避けることができるでしょう。

 マイクロサービスプラットフォームチームとしては、SLI/SLOという考え方を浸透させることがまず重要で、その後にサービス全体のSLOを俯瞰できるようなダッシュボードを整えていくのも一つのアイデアかなと思います。

カオステスティングとサービスメッシュの採用

 2つ目のアイデアはカオステスティングです。障害対応を開発者が行うことは、これまであまりありませんでしたが、これからは開発者自身が障害に対する一時対応を行う必要があります。

 カオステスティングの手法でわざと障害を起こし、問題になるコードをすぐ見つけるとか、障害が起きたことにすぐ気付けるかとか、そもそもモニタリングやアラートが動いているかを確認することができる。また、開発者が障害対応を経験することで、実際に障害が起きても落ち着いて対応できるようになる、という仕組みを作っていきたいと思っています。

 最後のアイデアはサービスメッシュです。モノリシックなアプリケーションでは、関数呼び出しで全てが完結しました。しかし、マイクロサービスにおいては、ネットワーク越しのコミュニケーションが大量に発生します。

 サービスメッシュを導入することで、サービス間のコミュニケーションのオブザーバビリティ(観察性)を改善するとか、ネットワークコネクションの信頼性を向上させるとか、セキュリティを強化することもできると考えています。

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


前のページへ 1|2|3|4       

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ