ShopifyのKubernetesとPaaSへの道程 - QCon NYでのNiko Kurtti氏の講演より

QCon New YorkでNiko Kurtti氏が、“Forced Evolution: Shopify's Journey to Kubernetes”と題したプレゼンテーションを行い、同社がKubernetesを基盤として独自のPaaSを構築した経緯について説明した。独自のPaaSとそれに関連する開発者ワークフローの構築を検討中のチームにとっては、デプロイメントと運用ユースケースの80パーセントを目標とすること、パターンを作成して下位プラットフォームの複雑性を隠蔽すること、周囲を教育してプロジェクトに関心を持たせること、ベンダによるロックインを意識すること、などが参考になるはずだ。

ShopifyのプロダクションエンジニアであるKurtti氏の講演は、Shopifyがカナダで急成長中のEコマース企業であり、オンラインストアと小売POSシステム用にプロプライエタリなEコマースプラットフォームを提供していることの紹介から始まった。Shopifyは現在3,000人を越える従業員を擁し、2017年には260億のトランザクションを処理しており、基盤となるEコマースソフトウェアプラットフォームには、ピーク時には1秒間80,000を越えるリクエストがある。

2016年初め、同社のエンジニアリングチームは、独自のデータセンタ(ChefとDockerを使用)やAWS(Chefを使用)、Herokuなど、“あらゆる場所でサービスを運用”していた。開発者たちはHerokuの開発環境を気に入っており、Kurtti氏はこのプラットフォームについて、“シンプルなUIスライダ”でインスタンス数や関連するCPUおよびRAMを増やすことが可能なため、スケールアップが非常に容易である、とコメントしている。プラットフォームチームでは、ビジネス上の重要性に従ってサービスティアと適切なSLO(Service Level Object)を定義していたが、スケール性のないプロセスが多数あったため、企業の成長にともなってこれらが課題となっていた。

手作業や職人的なプロセスは当然ながらスケール性に乏しい上に、プロセスの遅さが周りを待たせることになる、とKurtti氏は続けて述べている。プラットフォームやデプロイメント操作の中にあった“必要な時に動かない錆びたノブ”や、使ったことのない、あるいは信頼性の低いプロセスなどの問題も露見していた。これらの問題からShopifyは、テスト済みのインフラストラクチャ、常に期待通り動作するオートメーションに重点を置く必要性を認識するに至ったのだ。同じく拡張性において欠かせないのは、開発者がインフラストラクチャ/プラットフォーム全体を一貫した方法で安全に利用できることと、運用するシステムの専門家になるための包括的なトレーニングを提供することである。これら新たな活動と合わせて、クラウドコンピューティングの導入も決定したため、同社が選択したクラウドプロバイダであるGoogle Cloud Platform(GCP)への移行を進めたいと考えていた。

Shopifyのエンジニアリングチームは、効率的な社内PaaS(Platform-as-a-Service)の構築が必要であるという認識から、成功するためは3つの原則が重要であると判断した。すなわち、1) “舗装道路”の提供 -- デフォルトでShopify内の多くのユースケースに合致すると同時に、必要であればカスタマイズも可能であること(Netflixのエンジニアリングチームも昨年のQCon New Yorkで、同様のコンセプトを論じていた)。2) 複雑性の隠蔽 -- 基盤となるプラットフォームを知ることにもメリットはあるが、多くの開発者は、内部の詳細を提示されることを望んではいない。3) セルフサービスの優先 -- 中央集権的な運用やプラットフォームチームに待たされることで、開発者をボトルネックするべきではない。

分析と実験を行なった後、Shopifyチームは、Kubernetesコンテナスケジューラおよびオーケストレータ上にPaaSを構築することを選択した。Kubernetesはこの世界におけるオープンソースプロジェクトの最高の牽引役であり、プラットフォーム非依存で、公開API経由での拡張が可能であると同時に、GCP -- Google Container Engine (GCE) -- でもサービスとして提供されているため、チームはこの“強力な基盤”上に提供可能な付加価値コンポーネントに集中することができた。

次にKurtti氏は、Shopify PaaS上でアプリケーションを実行するためのビルディングブロックとして、アプリケーションのランタイムを参照する方法、アプリケーションの構築方法、アプリケーションのデプロイ方法、依存関係のセットアップ方法の4つについて言及した。それらに従ってエンジニアリングチームが開発したものが、“Services DB”と“Groundcontrol”というツールだ。Services DBは既存アプリケーションのカタログやKubernetesマニフェスト関連の自動生成メカニズム、継続的インテグレーション構成の構築などを含む、インタラクティブなWeb UIを開発者に提供する。GroundcontrolシステムはKubernetesクラスタに展開されるGo言語ベースのアプリケーションで、ネームスペースと暗号化キーの生成やサービスアカウントの管理を行う。Web UIの例を以下に示す。この例では、開発者がKubernetesクラスタのtestネームスペースに自動展開されるプロジェクトを生成するフローが表示されている。

さらに、DockerイメージをビルドするエージェントのPIPAと、PIPAのコーディネータとして動作するBuildkiteが追加ツールとして開発された。これらのツールは“Herokuish”ワークフローを提供するためにデフォルトで組み込まれる他、独自に用意したDockerfileの指定やカスタムパイプラインの作成に使用することもできる。また、“Kubernetesネームスペースの変更を送信し、その結果を解釈するコマンドラインツール”のKubernetes-deployも開発(およびオープンソースとしてリリース)されている。このツールはプラグイン可能で、デプロイの成功/失敗をシンプルな形で提供すると同時に、ConfigMapsやSecretsの設定、Kubernetesネームスペースの保護なども行う。これらツールはすべて、Shopifyが開発し、社内外で広く利用されているオープンソースのデプロイメントツール“Shipit”に統合されている。

プラットフォームチームは、CoreOSのOperatorパターンとほぼ同じ形式で、実質的にKubernetesのカスタム拡張である“cloudbuddies”の開発に多大な投資をしている。CloudbuddiesはKubernetes APIを拡張して、DNSレコードの生成やクラスタ/ユーザクォータの設定、セキュリティルールの設定などのプロセスを管理する。cloudbuddiesは新たなプラットフォームの成功に大きく影響している。Kurtti氏は、一般的にKubernetesの拡張が優れたエクスペリエンスである理由について、次のように論じている。1) Kubernetes APIはドキュメントが充実しており(“極めて安定している、とは言えないが”)、Go言語のクライアントライブラリの品質も高い。2) 現在の概念(デプロイメントやエンドポイントなど)は、拡張形式にすることも、(カスタムリソース定義を使って)カスタムエンティティにすることも可能である。3) 分散システムのプリミティブが提供されている。4) Kubernetesの拡張は純粋なGo言語で記述されているため、通常のアプリケーションと同じようにユニットテストや実行、デプロイが可能である。

プラットフォームチームは今のところ、コントロールプレーンを開発者に公開していない。kubectlなどのツールを使用する代わりに、提供されているWeb UIを通じてアプリケーションのデプロイや操作を行う。このUIはkubectlの機能の大部分を提供している他、将来的には開発チームの“パワーユーザ”を対象に、kubectl自体を公開する予定である。広範囲にわたるドキュメントも作成されている。これらのドキュメントは、“車の作り方”ではなく“車の運転方法”を重視 — すなわち、プラットフォームの技術的基盤の説明よりも、開発者エクスペリエンスやオペレーションを重視したものになっている。Kurtti氏はまた、業務時間内にオンコールのクラウドヘルプを提供している、ShipifyチームメイトのJenna Black氏の努力を称賛するとともに、サポート業務の専門知識を持つ(そして重要性を理解する)人たちとともに作業できたことが、非常に有益であったと述べている。

講演の最後には、新プラットフォームの“レポートカード”が論じられた。開発チームは、特にクラウドプラットフォーム上でのアプリケーション実行の容易さと、必要な時間の短さの点において、今回のプラットフォームを幅広く称賛している。しかしながら、課題も残っている。プラットフォームチームは現在、開発者向けの機能の動作状況の把握に努めると同時に、スケールアップやデバッグなど、開発上の共通的な問題への対処に注力している。プラットフォームSRE(Site Reliability)チーム自身は、(フルマネージドなGKEを導入したことによって)基盤となるインフラストラクチャのコントロール権を放棄せざるを得なかったため、一般的なユースケースすべてを満足する単一のプラットフォームを提供することが課題となっている。

独自のビルドを目指すエンジニアにとって、Kurtti氏とShopifyチームの事例は、いくつかの重要なテーマを与えてくれる — ユースケースの80パーセントを目標とすること、パターンを作って複雑性を隠蔽すること、プロジェクトについて教育して関心を持たせること、ベンダによるロックインを意識すること。

講演に関する詳細はQCon NYのWebサイトに、使用されたスライド(PDF)はスケジュールのページに、それぞれ公開されている。QCon NYの講演の大部分を収めたビデオが、今後数ヶ月にわたってInfoQで公開される予定だ。