JKD v18.12でWantedlyが語ったマイクロサービス導入の実態

昨今のエンジニア向けカンファレンスの傾向

ソフトウェアのカンファレンスでユーザーが成功事例を語るのは、そのユーザーの評判を上げるためには良い方法論だし、当該ソフトウェアが商用製品であれば、ソフトウェアメーカーにとってもありがたいことだろう。

しかしエンジニアが集うカンファレンスにおいて、あまりに「成功した」という側面だけを強調し過ぎると、逆効果なことが起こり得る。つまり余りに良い部分だけを開陳しても、エンジニアには響かないという状況が起こってしまうのだ。

個人的な感覚なのかもしれないが、昨今のオープンソースソフトウェアのカンファレンスでは「ここの部分は良い。でもあそこはまだ改善の余地がある。だからみんなで直していこう」という姿勢を取るコミュニティのエンジニアは多いし、ユーザーにおいても積極的にネガティブな部分を出すことで、リアリティのあるプレゼンテーションを目指す例を目にするようになった。

そのようなプレゼンテーションのJKDにおける例として、非常にユニークだったWantedlyのセッションを紹介したい。これは転職を支援するサービスを開発する際に、マイクロサービスを全面的に採用した開発の裏側を紹介するセッションだ。「Kubernetesがもたらす分散システムの脅威との戦い」というタイトルだけで、すでに良い話ばかりではないという雰囲気を感じることができる。プレゼンテーションを行ったのは、Wantedlyの坂部広大氏だ。

Wantedlyの坂部氏

またプレゼンテーションに利用したスライドも極力箇条書きを避け、文章で伝えようとするもので、印象的な内容となった。

話す内容を自然な文章で表現しており好感が高い

全体の構成も前半が良かったこと、後半がまだ解決しなければいけない課題というものになっており、後半に参加者が知りたい部分があるということを事前に知らせる形になった。

プロダクトに合わせて組織を変革？「逆コンウェイ戦略」

技術的な部分だけではなく、組織の作り方を作りたいプロダクトに合わせるという「逆コンウェイ戦略」を実践したということが後から出てくるが、組織を階層や機能で分けずに全体として考え、なるべくチーム単位に個別のノウハウ、つまり秘伝のタレが発生しないように気を付けていると言う辺りは、他の企業でも参考になるのではないだろうか。

組織全体で考える開発体制

オンプレミスのシステムではなくAWS、GCPに特化している辺りにもヒントがあるように思える。またパラメータのチューニングやキャパシティプランニングなど、アプリケーションデベロッパーと運用の中間の部分で積極的に自動化を進めることで、マイクロサービス以前に組織とツールをそれに合うように作り変えたということだろう。

組織の変化と運用のコツ

この後のスライドにも出てくるのが、他のオープンソースソフトウェアやプロジェクトの知見を積極的に探して活用しているという点だ。ここではKubernetesの開発のスタイルを参考にしながら、それを社内で応用していったという。

マイクロサービスを使う理由

マイクロサービスの役割を明確に定義し、他の依存関係を極力廃しながら、運用ではなく技術でハードルを越えようというのがWantedlyの姿勢だ。ここで、前述の逆コンウェイ戦略に触れている。

ただし、「新しい技術を使うためにソフトウェアを導入する」という発想については、明確に否定している。CI/CDのツールであるSpinnakerを、学習コストが高いという理由で採用しなかったということも、その一つだ。

シンプルに最小単位で補うのがポリシー

Kubernetesの管理ツールであるkubectlについては「デベロッパー向きではない、運用のためのコマンドが多過ぎる」と評価している。これは上海やシアトルのKubeConでも、様々なエンジニアやベンダーから出てきたコメントでもあり、そのために多くのベンダーがそれをWrapする独自ツールやコマンドを自製していることにも通じる部分だ。

マイクロサービス導入で直面した課題

そしていよいよ後半の課題、チャレンジの部分に説明は移っていく。

Wantedlyの課題

ここではモノリシックなアプリケーションでは発生しない様々な問題について解説を行ったが、それは分散システムを開発したエンジニアなら誰もが体験するものだろう。しかしそれ以前に、Kubernetes自体が分散協調のシステムであるということを忘れないほうが良いという。

Kubernetesが分散システムであるという覚悟

「覚悟」というのは「Kubernetesの管理担当を作るべきだ」という部分だろう。AWSやGCPを使うのであれば、インフラストラクチャーの運用管理は必要ないとは言え、Kubernetes運用のための知識が必要で、それを各デベロッパーが身に付けるというのが困難だという認識だ。

専任のKubernetes運用担当者が必要という知見

そしてネットワークを信頼しないこと、障害は常に起こるものとしてシステムを構築することなどが説明された。

ネットワークを信頼しないという認識

マイクロサービスが進化する次の段階として紹介されたのが、サービスメッシュだ。これはLinkerdの開発元であるBuoyantの発想として紹介している。

サービスメッシュはBuoyantのCTOが最初に考えたという

坂部氏のプレゼンテーションには、海外のブログ記事やプロジェクトのドキュメントから引用している要素が多いのが印象的だ。日本のソフトウェアエンジニアによく見られるQiitaの記事を参考にするだけではなく、積極的に海外のオリジナルのソースを読み込む姿勢が感じられる。

WeChatのシステムを参考に

また次のスライドでは、Twitterの分散トレーシングを紹介している。Buoyantの創業者2人が、Twitterで分散システムを開発していたことを考えると奇遇を感じる。

参考：Buoyantのインタビュー記事：サービスメッシュを実現するLinkerdの将来を、開発元のBuoyantが語る

Twitterの分散トレーシングを参考に

最終的なまとめとして、Kubernetesを全社で使いながら、組織の作り方、ツールの選び方、注意すべきポイントなどを明解に解説した。自分たちの経験を元に、他の企業にも応用できる内容を、わかりやすい日本語で説明するという素晴らしいプレゼンテーションだった。

Wantedlyの分散システムのまとめ