orangeitems’s diary

40代ITエンジニアが毎日何か書くブログ

メルカリのマイクロサービス/Kubernetes運用事例はバイブルだ

f:id:orangeitems:20191129120236j:plain

 

多くの人に見てほしいスライド

メルカリのマイクロサービス/Kubernetes運用事例を拝見しました。

 

speakerdeck.com

 

こちら、中身はメルカリにおけるマイクロサービス・Kubernetesの実際の運用状況をまとめた内容になっています。

この内容が欲しかった。

この世の中で、会社のITサービス基盤をKubernetesにてマイクロサービス化できている企業はほとんどいません。言い切ります。まだ仮想マシンのWEB+AP+DBの3層構成のままです。もしくは、AWS Lambraなどサーバレスでマイクロサービス化した事例は多数出てきていますがこれは基盤にKubernetesが使われている可能性はあるにしろ、ユーザーは意識していません。

Kubernetesをエンタープライズに適用する。このケースではGCEですが企業としてどのようなオペレーションになるのか、どういう思考錯誤があるのかが整理して描かれています。

ありがたい。

というのは、今まだ、ベストプラクティスが定まっていないからです。ITILなど運用のお手本とされているIT業界の常識は、メルカリがやりたいことと乖離していると思います。新しいことをやるためにベストプラクティスがないのは当然です。それを今作っているのがメルカリのチャレンジであり、その成果物がこのように無償公開されているのは、ありがたい、と言う言葉以外にありません。

 

考察

そもそも、なぜマイクロサービスを使う必要があるのか。

新しいから、GAFAが使っているから。それは表層的な理由だと思います。

ただただ流行しているだけでテクノロジーを使うと、痛い目に遭うだけです。戦略があって使うのです。

経営者のインタビューにコメントがあります。

 

diamond.jp

――ロールモデルにしている企業はありますか。

 あらゆる企業の“いいとこ取り”をしていくしかないと思っていますが、あえて言えば、中国の会社はものすごく進んでいますね。(中略)自社サービスと組織の仕組みがマッチしているんです。

ものすごい進んでいるので当社も早く追いつきたいのですが、どう行けばいいのか悩んでいる状況です。そのために、マイクロサービス化を進めていたり、データの裏側を作り替えたりしています。

 

ビジネスが急拡大するにあたって、組織を最適化しなければいけない。

自社サービスの拡大と、組織の仕組みが一致させたい。

その具体的方法がマイクロサービス化だということになります。

 

 これまでは、社内全体に目が届いていたので、違う動きをする社員がいても軌道修正できていました。でも今は、毎日あらゆる人が入社し、メルカリ社内は急速に“村から町へ”変わっています。すると途端に、社員の細かい動きが見えなくなり、いつの間にか違う方向に進んでいってしまう。結果的に思わぬロスが生まれたり、同じことを別のチームが重複して進めてしまったりしてしまいます。

 

社員数が増大したことで、複数の物事を複数の技術者が進めるようになった。したがって組織が小さい時のままワークフローを変えないと、経営者の意図通りに組織が進まなくなっていく。社員に権限を明確に与えつつ、全体が破綻しないようにするためのマイクロサービスだということがわかります。

 

さて、このマイクロサービスの実装方法ですが、次にCTOのスライドを参考にできます。

 

logmi.jp

マイクロサービス化を長いことやっているんですけど、要は意思決定を各エンジニアができるようにするために、マイクロサービスやフロントエンドのコンポーネントや、諸々を整備しています。

あとは、エンジニアの評価制度が(国ごとの)カルチャーによって変わってくるので、そういったところのprincipleを作ったり、Career Ladderという、どれぐらいどういう期待値で仕事をすると「あなたの評価はこうなります」ということをちゃんと明文化するようにしたり。
あとは、グローバル人材を育成するには英語を主体にしていく必要があるので、言語面での研修のサポートなどを積極的に進めています。

今後はマイクロディシジョンというか、意思決定をどんどんエンジニアのほうでしていくために、属人性の排除もそうですし、意思決定をデータドリブンにしなければいけないので、そういったところを支えるFeature Flagとか。あとはエンジニアがデザイナーの力を得なくても機能実装ができるようにするためのDesign Systemとか。

あとは、Microcomponentsと言っていますが、フロントエンドサイドの細分化を進めたり、データディシジョン、データドリブンという、意思決定をするためのプラットフォームを整備したり、基盤整備部分を一生懸命進めています。

メルカリが、プロダクトが成長して、かつ、エンジニア組織が数百人規模になって、そのうち4割ぐらいが外国人で構成されるような特異な組織になってきたんですけど、そういった中でいいプロダクトを作るための組織とか技術に関して、今は道半ばで課題がすごく多いけれど、進んでいるという共有をさせていただきました。

 

もっと具体的に、技術目線で言葉にしてあるスライドです。

こういったバックボーンを踏まえて、冒頭のマイクロサービス運用事例を見るべきです。

 

考察2

さて、冒頭の資料の素晴らしいところって、「いいところ」だけではなく「大変なところ」を公開してくれているところです。

「マイクロサービスの運用は大変」というスライドの通り、今手を付けると大変なことだらけなのが現実です。

それにどう対応すればいいかの積み重ねがベストプラクティスです。

どんどん洗練されていった結果、多くの人が使うようになります。

どんな技術でもそうです。はじめは大変なこと、想定外なことだらけです。

運用が楽するためにマイクロサービスを選ぶとしたら、それは現時点では誤りだと思います。

今までの監視とは、ハードウェアや仮想マシンが健康かどうか、と言う観点でした。しかしマイクロサービスになると、コンテナが健康かというより、まずはKubernetesが健康かどうかという観点が重要となります。コンテナが不健康ならばKubernetesが健康な状態に自動でしてくれるのが売りだからです。しかしKubernetes自体が不健康だとコンテナを是正してくれません。

コンテナについては、リソース監視よりログ監視が重要だという話も良く聴きます。マイクロサービスは機能が爆発的に増えていくので、一個一個監視してられないと。ひとまとめの機能をログで横断的に見て、どこかにボトルネックが発生していないか見るような監視にしないといけないと聞きます。

 

Cloud Nativeで重要なのは技術セットではない

組織体制や開発・運用のスタイルも含めたCulture

 

これって金言だと思います。

だから、コンテナを利用することと、マイクロサービスの思想はきっちり分けなければいけないと思うのです。

日本の会社が、全てメルカリのような組織構造になる、なんて、絵空事のように聞こえます。組織構造を変えないのであれば、旧来のモノリシックなデザインの方が向いていると思います。一方で、コンテナはコンテナで使えばいいと思うのです。

 

経営者のビジョンから、CTOのプレゼン、そして現場の運用のプレゼンまで追いかけていくと、マイクロサービスの根幹というか目的がはっきりわかると思いますがいかがでしょうか。

マイクロサービスは、単に技術者が楽をするための話ではありません。経営や組織論まで及ぶのです。したがって、本件技術者だけではなく多くの人に知ってほしいと思います。