クラウドを活用したEtsyのスケーリング

戦略原則

マイク・フィッシャー（CTO）とケユール・ゴヴァンデ（チーフアーキテクト）は、以下の原則に基づいて最初のクラウド移行戦略を作成しました。

実用最小限の製品 - Etsyが避けたい典型的なアンチパターンは、再構築が多すぎて移行が長引くことでした。代わりに、リーンの概念であるMVPを使用して、Etsyのシステムがクラウドで動作することを可能な限り迅速かつ安価に検証し、データセンターへの依存をなくしました。

ローカルでの意思決定 - 各チームは、プログラムチームの監督を受けながら、自分が所有するものについて独自の意思決定を行うことができます。Etsyのプラットフォームは、コンピューティング、オブザーバビリティ、MLインフラなどの機能と、検索、入札エンジン、通知などのドメイン指向のアプリケーションスタックに分割されていました。各チームは、移行計画を策定するための概念実証を行いました。メインのマーケットプレイスアプリケーションは、非常に大きなモノリスであることで有名であり、それに焦点を当てたチーム横断的なイニシアチブを作成する必要がありました。

開発者エクスペリエンスの変更なし - Etsyは、質の高い開発者エクスペリエンスを生産性と従業員の幸福にとって不可欠なものと考えています。クラウドベースのシステムが、迅速なフィードバックや高度なオブザーバビリティなど、開発者が依存している機能を引き続き提供することが重要でした。

また、非常に達成したいと考えている既存のデータセンターの契約に関連する期限もありました。

パートナーの活用

クラウド移行を加速させるために、EtsyはTerraform、Kubernetes、Prometheusなどの新しいツールやテクノロジーの導入を支援する外部の専門知識を取り入れたいと考えていました。Thoughtworksの典型的なクライアントとは異なり、Etsyにはエンゲージメントの根本的なニーズを駆り立てる切迫したプラットフォームがありませんでした。彼らはデジタルネイティブ企業であり、ソフトウェア開発に徹底的に現代的なアプローチを使用していました。焦点を当てるべき単一の問題がなかったとしても、Etsyは改善の余地があることを知っていました。そのため、エンゲージメントのアプローチは、プラットフォーム組織全体に組み込むことでした。Thoughtworksのインフラストラクチャエンジニアとテクニカルプロダクトマネージャーは、検索インフラストラクチャ、継続的デプロイメントサービス、コンピューティング、オブザーバビリティ、機械学習インフラストラクチャチームに加わりました。

段階的な連合型アプローチ

マーケットプレイスモノリスのクラウドへの最初の「リフト＆シフト」は、最も困難でした。チームは、最小限の変更でモノリスをそのまま維持したいと考えていました。しかし、LAMPスタックを使用していたため、リプラットフォーム化は困難でした。パフォーマンスとキャパシティをテストするためのドライランを何度か行いました。最初のカットオーバーは失敗しましたが、すぐにロールバックすることができました。典型的なEtsyのスタイルで、失敗は称賛され、学習の機会として利用されました。最終的には、当初計画していた1年未満の9か月で完了しました。最初の移行後、モノリスはクラウドに適応するように調整され、自動スケーリングや不良ノードの自動修正などの機能が追加されました。

一方、他のスタックも移行されていました。各チームは独自のジャーニーを作成しましたが、チームは完全に孤立していたわけではありません。Etsyは、チーム横断的なアーキテクチャ諮問グループを使用して、より広範なコンテキストを共有し、社全体でパターンマッチングを行うことを支援しました。たとえば、検索スタックはクラウドの一部としてGKEに移行しましたが、これはモノリスのリフトアンドシフト操作よりも時間がかかりました。別の例は、データレイクの移行です。EtsyはオンプレミスのVerticaクラスタを持っていましたが、それをBigQueryに移行し、その過程ですべてを変更しました。

Etsyにとって驚くことではありませんが、クラウド移行後もクラウドの最適化は止まりませんでした。各チームは、クラウドを最大限に活用する機会を探し続けました。アーキテクチャ諮問グループの助けを借りて、業界標準ツールに移行することでカスタムコードの量を削減する方法、コスト効率を改善する方法、フィードバックループを改善する方法などを検討しました。

図1：連合型クラウド移行

例として、オブザーバビリティとMLインフラの2つのチームのジャーニーを見てみましょう。

すべてを観測することの課題

Etsyは、「動いているものはすべて追跡する」という、すべてを測定することで有名です。運用メトリクス（トレース、メトリクス、ログ）は、会社全体で価値を生み出すために使用されます。プロダクトマネージャーとデータアナリストは、計画を立て、アイデアの予測値を証明するためにデータを利用します。製品チームは、担当領域の稼働時間とパフォーマンスをサポートするために使用します。

Etsyのハイパーオブザーバビリティへのコミットメントにより、分析されるデータ量は少なくありません。オブザーバビリティはセルフサービスです。各チームは測定するものを決定できます。サイトとサポートインフラストラクチャをカバーする8,000万のメトリクスシリーズを使用しています。これにより、1日に20TBのログが作成されます。

Etsyが最初にこの戦略を開発したとき、彼らの厳しい要件に対応できるツールやサービスは市場にはあまりありませんでした。多くの場合、彼らは独自のツールを構築せざるを得ませんでした。その例が、現在オープンソース化され、業界全体で使用されている統計集計ツールであるStatsDです。時が経つにつれて、DevOpsムーブメントが爆発的に増加し、業界は追いつきました。Prometheusなどの革新的なオブザーバビリティツールが多数登場しました。クラウド移行により、Etsyは市場を評価し、サードパーティツールを活用して運用コストを削減することができました。

オブザーバビリティスタックは、その複雑な性質のため、最後に移行されました。リフトアンドシフトではなく、再構築が必要でした。彼らは大型サーバーに依存していましたが、クラウドを効率的に使用するには、多くの小型サーバーを使用し、水平方向に簡単に拡張する必要があります。スタックの大部分をマネージドサービスとサードパーティのSaaS製品に移行しました。この例としては、トレース処理をアウトソーシングするために使用できるLightstepの導入が挙げられます。Etsyが依存している独自のシナリオを処理するためには、ある程度の処理を社内で行う必要がありました。

クラウドへの移行により、より優れたMLプラットフォームを実現

Etsyにおけるイノベーションの大きな源泉は、機械学習の活用方法です。

Etsyは、最先端の検索、広告、推奨事項を使用して、世界中の何百万人ものバイヤーにパーソナライズされたエクスペリエンスを作成するために、機械学習（ML）を活用しています。EtsyのMLプラットフォームチームは、EtsyのML実践者がMLモデルのプロトタイピング、トレーニング、大規模なデプロイに依存している技術インフラストラクチャを開発および保守することにより、機械学習実験をサポートしています。

-- Kyle Gallatin and Rob Miles

クラウドへの移行により、Etsyはマネージドサービスに基づく新しいMLプラットフォームを構築することができ、運用コストを削減し、アイデアの生成から本番環境へのデプロイまでの時間を短縮することができました。

リソースがクラウド内にあったため、クラウド機能に依存できるようになりました。ETLにはDataflowを、モデルのトレーニングにはVertex AIを使用しました。これらのツールで成功を収めたため、他のツールにも拡張できるようにプラットフォームを設計しました。広くアクセスできるように、TensorFlowやKubernetesなどの業界標準ツールを採用しました。MLの開発とテストにおけるEtsyの生産性は、以前のパフォーマンスを飛躍的に向上させました。RobとKyleが述べているように、「アイデアから実際のML実験に移行するまでの時間が約50％短縮されると推定しています。」

しかし、このパフォーマンスの向上は、課題がないわけではありませんでした。データの規模が大きくなるにつれて、高性能コードの重要性も高まりました。パフォーマンスの低いコードでは、カスタマーエクスペリエンスに影響を与える可能性があるため、チームは高度に最適化されたシステムを作成する必要がありました。「ベクトル化されていないコードなどの小さな非効率性は、パフォーマンスの大幅な低下につながる可能性があり、場合によっては、単一のテンソルフロートランスフォーム関数を最適化することで、モデルの実行時間を200ミリ秒から4ミリ秒に短縮できることがわかりました。」数値的には2桁の改善ですが、ビジネスの観点からは、これは顧客が容易に認識できるパフォーマンスの変化です。

クラウドの課題とは何だったのか？

Etsyは独自のインフラストラクチャを運用する必要があり、プラットフォームチームのスキルの多くはシステム運用にありました。クラウドへの移行により、チームはInfrastructure as Codeによって管理される、より高度な抽象化を使用できるようになりました。彼らはインフラストラクチャの採用において、ソフトウェアエンジニアリングのスキルを持つ人材を求めるように変更しました。これは既存のチームとの摩擦を引き起こしました。一部の人は非常に興奮していましたが、他の人は新しいアプローチに不安を感じていました。

クラウドは確かに管理する必要がある事項の数を減らし、よりシンプルな計画を可能にしましたが、キャパシティプランニングから完全に解放されたわけではありません。クラウドサービスは依然としてCPUとディスクを搭載したサーバー上で実行されており、状況によっては、将来の負荷に合わせた適切なサイジングを行う必要があります。今後、オンデマンドのクラウドサービスが向上するにつれて、Etsyはこのキャパシティプランニングを削減できることを期待しています。

パンデミックのストレステスト

Etsyは常にデータセンターベースであり、それがいくつかの点で制約となっていました。データセンターへの投資が非常に大きかったため、クラウドベンダーが開発した新しいサービスを利用していませんでした。たとえば、データセンターのセットアップには、プロビジョニングと容量を管理するための堅牢なAPIがありませんでした。

マイク・フィッシャーが就任したことで、Etsyはクラウド移行の旅を始めました。この移行はパンデミックの開始時に基本的に完了していたため、将来の成功への道が開かれました。これはいくつかの形で現れました。トラフィックはイベントが10億から60億に増加したため、一夜にして2～3倍に急増しましたが、容量不足はありませんでした。

また、パンデミックの際にクラウドが俊敏性をもたらした具体的な例がいくつかありました。たとえば、クラウドは「意味的ギャップ」を埋める取り組みを可能にし、「マスク」の検索で化粧品やコスチュームのフェイスマスクではなく布マスクが表示されるようにしました。これは、Google CloudによってEtsyがより高度な機械学習を実装し、アルゴリズムをリアルタイムで再トレーニングする俊敏性を実現できたためです。もう1つの例は、データベース管理がデータセンターからクラウドに変更されたことです。具体的には、バックアップに関して、EtsyのDR体制はクラウドで向上しました。これは、ブロックストレージのスナップショットをデータベースの復元方法として活用したためです。これにより、高速な復元が可能になり、信頼性が高まり、迅速にテストできるようになりました。以前の方法では、復元には数時間かかり、完全にスケーラブルではありませんでした。

Etsyは広範な負荷テストとパフォーマンステストを実施しています。彼らはカオスエンジニアリングの手法を用いて、システムを最大容量で負荷をかける「スケールデー」を設けています。パンデミック後、増加した負荷はもはや一時的なものではなく、毎日の平均となりました。負荷テストのアーキテクチャと手法は、成長に対応するために、他のシステムと同様にスケーラブルである必要がありました。

プラットフォームの継続的な改善

Etsyの次の重点分野の1つは、エンジニアのための「舗装された道」を作ることです。サービスの立ち上げと開発における摩擦を軽減するための一連の推奨アプローチと仕組みです。クラウド移行の最初の4年間、彼らは非常に連合的な戦略を採用することを決定しました。彼らは、Peter SeibelがTwitterのエンジニアリング効率に関する記事で述べているように、「百花繚乱」のアプローチを取りました。システムはクラウドに存在したことがありませんでした。彼らはどのような成果が得られるかわからず、クラウドの価値を発見する可能性を最大限に高めたいと考えていました。

その結果、Etsyには既存の実装パターンとサービスがないため、一部のプロダクトチームは車輪の再発明を行っています。クラウドでの運用経験が豊富になった今、プラットフォームチームはギャップがどこにあるかを理解し、ツールが必要な場所を把握できます。

投資が成果を上げているかどうかを判断するために、Etsyはさまざまな指標を追跡しています。たとえば、システムの信頼性、デバッグ可能性、可用性に関連するSLI/SLOの傾向を監視しています。もう1つの重要な指標は、Time to Productive、つまり新しいエンジニアが環境をセットアップして最初の変更を行うまでに必要な時間です。それが具体的に何を意味するかはドメインによって異なります。たとえば、最初のWebサイトのプッシュ、またはビッグデータプラットフォームで動作する最初のデータパイプラインなどです。以前は2時間かかっていたものが、今では20分で完了します。

彼らはこれらの定量的な指標と、エンジニアの満足度を定期的に測定することを組み合わせています。NPS調査の一種を使用して、エンジニアがそれぞれのエンジニアリング環境でどのように仕事を楽しんでいるかを評価し、問題点を指摘し、改善を提案する機会を提供しています。もう1つの興味深い統計は、インフラストラクチャが10倍のノードを使用するように拡張されましたが、管理に必要な人員は2倍に過ぎないということです。

コストと炭素消費量の測定

Etsyはすべてを測定することを引き続き重視しています。クラウドに移行することで、チームはデータセンターに比べて運用コストを特定し、追跡することが容易になりました。EtsyはGoogle Cloud上にツールを構築し、支出に関する洞察を提供するダッシュボードを提供することで、チームがどの機能がコスト増加の原因となっているかを理解できるようにしました。ダッシュボードには、最適な効率性についての理解に基づいて測定された、最適化の意思決定に役立つ豊富なコンテキスト情報が含まれていました。

非常に重要な企業の柱は持続可能性です。Etsyは四半期ごとのSEC提出書類でエネルギー消費量を報告し、それを削減することを約束しています。彼らはデータセンターのエネルギー消費量を測定していましたが、クラウドでこれを行うことは当初はより困難でした。Etsyのチームは、エネルギー推定ツールであるCloud Jewelsを研究開発し、オープンソース化しました。

私たちは、2025年までの主要なインパクト目標の1つであるエネルギー強度を25％削減するという目標に対する進捗状況を測定することができませんでした。クラウドプロバイダーは一般的に、顧客にサービスがどれだけのエネルギーを消費しているかを開示していません。このデータの不足を補うために、クラウドの使用状況情報（Google Cloudの使用状況データなど）を概算のエネルギー使用量に変換するのに役立つ、Cloud Jewelsと呼ばれる一連の変換係数を作成しました。私たちの仕事と方法論が、GoogleとAWSによって独自のモデルとツールに組み込まれていることを誇りに思います。

-- エミリー・ソマー（Etsyサステナビリティアーキテクト）

これらの指標は最近、製品ダッシュボードに追加され、製品マネージャーとエンジニアはエネルギー消費を削減する機会を見つけ、新機能が何らかの影響を与えたかどうかを確認できるようになりました。同様の持続可能性の使命を持つThoughtworksも、Cloud Jewelsの初期調査に触発され、Thoughtworksの社内チームによってさらに開発された、Cloud Carbon Footprintと呼ばれるオープンソースツールを作成しました。