AutoScout24のマイクロサービスへの旅: 変革・原則・技術についてのChristian Deger氏へのインタビュー

Dublin Microservices User Groupにおいて、Christian Deger氏は「Highway to Heaven: Building Microservices in the Cloud」というタイトルで発表を行った。これは、AutoScout24において、従来型のIT開発プロセスを用いてコードをモノリシックなアプリケーションとしてデプロイするところから、 クロスファンクショナルチームによって開発されデプロイされるマイクロサービスアーキテクチャーの活用に至るまでの旅についてのものだ。この技術的・組織的な変革によってビジネスがマーケットの状況変化に素早く対応することが可能になった。

InfoQは先日AutoScout24のアーキテクトであるDeger氏と話す機会を得て、大規模な変革を進める上でのプロセスと課題について質問した。氏は組織や技術において変革を進める動機を共有し、必要とされる計画づくりについて論じ、Linux・Scala・AWSという技術的選択に関する洞察を提供してくれた。

InfoQ: ようこそChristian！。自己紹介と「Highway to Heaven」のマイクロサービスに関するプレゼンテーションにおいて核となる考えについて説明をお願いできますか？

Deger: 私は5年以上前に.NETのソフトウェア開発者としてAutoScout24に入社しました。ですから、以前の世代の技術スタックがどうなっていたのか、それをサポートする組織がどうなっていたのかを見ることができたのです。2014年の初頭にGreg Ellisが新しいCEOに就任しましたが、彼はWindows .NETスタックの将来について疑問を持ち続けていました。その時、私は開発者のチームを率いていました。しかし成熟していたITを次世代の「ウェブスケール」ITプラットフォームに変革するという挑戦が、私をアーキテクトして技術的な役割を果たすよう誘ったのです。

私たちはTatsuプロジェクトを2014年11月に1チームで開始しました。そしてここまでで8チームが立ち上がり、変革プロジェクトのために働いています。Tatsuという名前は日本の神話に由来するもので、空を飛ぶ獣です。またTatsuはカリフォルニアにあるジェットコースターの名前でもあります。ですから、Tatsuは私たちがどんな旅を経験するかを表すとても適切な説明だったのです。本物のジェットコースターと同じように、掴まるものがあるのは良いことです。私たちの場合、自分たちで考えて絶えず発展させてきた原則がそれにあたります。これらの原則は、議論の案内役となり、私たちを正しい方向に保ってくれています。ですから、話の内容は、私たちのアプローチ・原則・経験したことに関するものになります。

InfoQ: AutoScout24におけるモノリシックからマイクロサービスへのマイグレーションは大規模プロジェクトだったと思います。どれくらい事前に計画しましたか？

Deger: AutoScout24にとって本当に大規模プロジェクトですが、私たちは大きな事前計画は信用していません。もちろんキャパシティや予算計画のためのデューデリジェンスはしました。でも、私たちにとっていちばん大事なのは、しっかりした最初の決断を下すことだったのです。AWSとLinuxは疑う余地のない選択でした。JVMとScalaを選択するのは容易ではありませんでした。ですが、私たちの.NETでの経験から、これらがよい開始点だろうと考えました。エンジニア間での言語に関する議論は避けられませんが、AutoScout24でもScalaについては白熱した議論がありました。マイクロサービス化したいと考えて多言語の利用に発展したことが、大きな助けとなりました。

それから、これらの領域で私たちをサポートしコーチしてくれるパートナーを探そうとしました。しかし、最終的に、私たちは最初のマイクロサービスとして書き直しをした能力こそがパートナーになると判断しました。最初のチームとして学習し適応したこと全てが役にたちました。

InfoQ: マイクロサービスへの移行に加えて、クラウドへの移行と.NET/WindowsからJVM/Linuxへの切り替えを選択したことについても言及されていたと思います。後から考えて、他の人にこのような変革を実行するよう勧めたいと思いますか？

Deger: 私たちにとって、全体の変革と核になる意思決定は、それぞれが密接に絡まったパズルのピースのようなものです。小さなステップに分けて変化することももちろんできたでしょうが、それは格好の機会を逃すことになります。私たちの業界では次の課題がどんどんやってきます。ですから、後から考えても、私は核になる意思決定については変えないと思います。

同時にすべてを変えるにあたって、まず1チームから始めて学習に重点を置くことで、組織への影響を限定するようにしました。2・か月ごとに新しいチームができ、経験のあるエンジニアとプロジェクトに新しくきたエンジニアを混ぜるようにしました。これは最初の何チームかはとてもうまくいきました。しかし、このチームの細胞分裂をいつ止めるのかを知ることが鍵になるというのも学びました。学習フェーズが終わってデリバリに焦点が移ったとき、私たちはチームの固定化を許容しなければいけません。

ｭ

技術面では、JVMやLinuxについてはまだ大量に学習することはありますが、全てを自動化することに成功しました。私たちのイミュータブルなサーバを含む全てのインフラストラクチャはコードで記述されています。これらの問題をWindowsの技術スタックを使って解決したいとエンジニアが言っているのを聞いたことがありません。

InfoQ: 「開発」環境と「本番」環境しか作らなかった理由と、そこにステージング環境がない理由についてもう少し説明いただけますか？

Deger: 私がAutoScout24で働き始めたとき、3つのステージング環境と1つの本番環境がありました。全てのステージに適したリリース候補を作ることにいつも苦労していました。本番環境と設定が違っていたためです。さらにステージング環境の「セーフティネット」は常に本番での失敗を防いでくれるわけではありませんでした。データや負荷やアクセスのパターンが異なっていたからです。

加えて、複数のサービスを個別にリリースする際、本番と異なるバージョンの他サービスと連携してしまい、全サービス用のステージング環境が問題を引き起こしていました。他のサービスはデリバリーサイクルの途中だったのでしょう。なぜステージング環境を持つという苦労をしないといけないのでしょうか？全サービスが利用可能なたった1つの環境を持つようにした方がシンプルではないでしょうか？

私たちは愚かではなく「勇敢」でありたいと思っていました。ですから安心して直接本番環境にデプロイするには何が必要なのかを調査しました。サービス自体が壊れていたり、新機能が期待どおりに動かない。サービス間の連携が壊れている。こういったことをなんとかしたかったのです。

• 動的なフィーチャートグルは機能のリリースとコードのデプロイを切り離すのに役立ちました。これによって新機能のリリースを完全にコントロールできるようになりました。私たちは2年以上前に独自のツールを作りました。これはFeatureBee (https://github.com/AutoScout24/FeatureBee) と呼んでおり、カナリアリリース・A/Bテスト・ユーザ受け入れテストをするのに使っています。例えば、AutoScout24の誰でもChromeの拡張を使うことで、自分自身で新機能を有効にすることができます。ちょうど最近、Pete Hodgson氏がMartin Fowler氏のウェブサイト(http://martinfowler.com/articles/feature-toggles.html)でこのコンセプトについて説明しています。
• Consumer-Driven Contracts CDC (訳注：デザインパターンの1つ) (http://martinfowler.com/articles/consumerDrivenContracts.html) は本番環境で動作しているサービスがContractを壊していないか確かめるのに役立ちます。サービスは、Consumerによって提供される現在のContractに関するテストをパイプラインの中で実行します。そこではデプロイ済のサービスと連携する必要はありません。現在、これらのテストのために、Pact (https://github.com/realestate-com-au/pact) に移行中です。
• 新しいサービスへのシャドートラフィックの送信は、本番化する前にパフォーマンス問題を解消するのを可能にします。この昔からあるアプローチは、状態を変えてしまうサービスには役立ちませんし、リリース後にも役立ちません。そこで、シャドートラフィックを流すためのインスタンスレベルでのカナリアリリースを調査しています。これを機能させるためには、カナリアリリース中に書き込まれたデータにフラグをつけて本番では使われないようにする必要があるでしょう。

InfoQ: マイグレーションの中で必要となる技術的な変化と同時に、「自律的なチーム」を作ることはどれくらい重要なのでしょうか？

Deger: 私たちにとって自律的なチームを作ることはとても重要でした。自律的なチームによって速い速度のまま組織を拡大することが可能になると信じているからです。自由と責任の文化はとても強力です。

私たちの以前のチーム構成は既に部分的には機能横断的でした。一番問題があったのは、運用に対してまだ引き継ぎが発生していたことです。そこで運用チームの人間を製品チームに組み込み、サービスを動かし改善することをチーム全体の責任にするようにしました。「今や私たち全員がエンジニアです」というモットーを広めました。

私たちは、異なった「T型」のチーム構成が、チーム全体の能力にどれくらい貢献するのかをまだ注視しなければいけません。過去のふるまいに戻ってしまうのはとても簡単です。運用のバックグラウンドを持つエンジニアだけがインフラストラクチャのストーリに着手するのであれば、彼らがそのチームの中での単一障害点になります。 「You build it, you run it」の中の「You」が確実にチーム全体を意味するようにしないといけません。一方で、多くのエンジニアがスキルを向上させる機会を得ているのはとても素晴らしいことです。

InfoQ: 「原則」の箇所の話をとても興味深く思いました。このマイグレーションを通じて学んだ一番重要な原則は何でしょうか？

Deger: 「シェアードナッシング」の原則についてたくさんの価値ある議論がありました。この原則を共有すべきなのはもちろんですが、この原則には説明が必要です。共通のふるまいはサービスであるべきで、サービス間でデータストアを共有すべきでないのは明らかです。元からのふるまいが変わると重要なものが生まれます。私たちはDRYであるよう、標準化するよう訓練されています。多くのエンジニアが共通ライブラリを作りたがります。でも、共通ライブラリは、サービスを具体的な実装や根本にあるプラットフォームと結合してしまいます。私たちは、効率のために最適化したいのではなく、速い速度であるために最適化したいのです。

例えば、私たちは一元管理されたログ用のインフラストラクチャを共有しています。これはマクロな要求です。全てのサービスからのイベントを関連付ける必要があるからです。このインフラストラクチャに加えて、イベントのデータ規約も共有されています。でもイベント発行の初期実装は共有していませんでした。単に1つのクラスをコピーすることについて強い反対があったのです。すぐにチームは、他と連携することなく、自分たちの必要性にもとづいて自分たちのバージョンを進化させました。何か月もたって実装が安定したのちに、最終的に全ての改善を取り入れて内部のオープンソースライブラリに組み込みました。新しいチームはそのライブラリを使うかどうか選べるようになっています。

別の例として私たちのダッシュボードサービスがあります。最初のチームがDashingのサーバをセットアップし、2番目のチームは同じインスタンスに別のダッシュボードを追加するだけでした。偶然、両方のチームでメトリクスの1つとして同じグローバルな状態を利用していました。2日後、両方のダッシュボード間で5分ごとに値を実際に切り替えているのを見つけました。これはとても酷い結合の例です。いまは全てのチームで専用のDashingサーバを運用しています。

2番目の原則は、物議をかもすことなくとても役立つもので、AWSファーストです。「マネージドサービスより、自分でホスティングしたオープンソースより、自分で展開したソリューションよりもAWSのプラットフォームサービスを」ということです。私たちはどのプラットフォームを自分たちのスタックの一部とするか決める必要がありました。そして、私たちはマネージドサービスの恩恵を受けるためにAWSを使いたいと考えていたのを思い出したのです。私たちは差別化にならない力仕事を避けて、自分たちのドメインに集中し高速であるべきです。まだ他のオプションも選べますが、そうするのに相応しい理由がある場合に限っています。

「Highway to Heaven: Building Microservices in the Cloud」のビデオはYoutubeで視聴できる。スライドは、SlideShareのDegerのアカウントからダウンロードできる。