Acquia Cloud Next - 大規模プラットフォームのクラウドジャーニー
Acquia Cloudは、2009年にAcquia Hostingとして初めて発表されました。アクイアはAWSをいち早く採用した企業の1つです。当時、AWSにはEC2、S3、SimpleDBの3つのサービスしかありませんでした。
その後、皆さんもご存知の通りクラウド技術は多くの革新が行われ、アクイアではその結果、2019年後半からAcquia Cloudのインフラを再設計することになりました。Acquia Cloud Next（ACN）と名付けられたこの取り組みは、アクイアの歴史上、最大のリプラットフォームプロジェクトとなりました。
Acquia Cloudのローンチから4年後の2013年にはDockerが登場しました。Dockerは、軽量のコンテナランタイムと、アプリケーションのパッケージ化、配布、デプロイを簡単に行う方法を世界中に普及させました。
Dockerは、cgroups、User Namespace、Linux containersなど様々なLinuxカーネルの機能に基づいてビルドします。
- 2006年にPaul Menage氏(Google)がLinuxカーネルにGeneric Process Containersを提供し、後にControl Group(cgroups)と改名されました。
- 2008年には、Eric W. Biederman氏(Red Hat)がUser Namespacesを発表しました。これは、Linuxプロセスが独自のユーザーセットを持つことを可能にし、特にプロセスコンテナ内でroot権限を持つことを可能にします。
- 2008年にIBMはcgroupsとUser Namespacesの上に、Linux Containers Project(LCP)と呼ばれるツール群を作成しました。
Dockerは、1台のマシンにコンテナをデプロイすることに重点を置いていました。組織が数多くのマシンにわたってDockerを採用し始めたとき、コンテナオーケストレーターの必要性が明らかになりました。
Dockerが誕生する前の2000年代初頭、Googleはコモディティ・ハードウェア上で検索エンジンを構築したことで有名です。競合他社が高価なエンタープライズグレードのハードウェアを使用していたのに対し、GoogleはLinuxを実行する安価なハードウェアでより速くスケールできることにいち早く気づきました。これは、ソフトウェアがハードウェアの障害に対処できる限りにおいて有効でした。耐障害性のあるソフトウェアを構築するための鍵は、コンテナを使用することでした。そのためにGoogleは、cgroupsやUser Namespacesの開発に貢献しただけでなく、Borgという自社開発のコンテナオーケストレーターを構築しました。
Dockerが爆発的に普及すると、Borgプロジェクトに携わるエンジニアはKubernetesの開発へと枝分かれしていきました。2014年にGoogleがKubernetesをオープンソース化し、その後数年でKubernetesは世界をリードするコンテナ管理システムに成長しました。
アクイアに話を戻します。2019年末には、Acquia Cloudのインフラはひと月あたり約350億PV（CDNを除く）を配信していました。アクイアのインフラは、多くのAWSリージョンに広がる数万台のEC2インスタンスに成長していました。オリンピック、全豪オープン、Weather.com、ミューラーレポートを含む、世界で最もトラフィックの多いイベントをサポートしました。
2019年を通して、私たちはAcquia Cloudに多くの改善を行いました。このおかげで、お客様のサイトでは30％〜60％のパフォーマンス向上が無償で実現されました。
しかし、既存のプラットフォーム上でこれ以上の改善を行うことは難しくなってきました。私たちの規模では、EC2インスタンスのフリートに改良を加えるのに数週間かかることもありました。Acquia Cloudをゼロから再設計することに着手し始めたのはこの頃でした。
我々のACNジャーニーはKubernetesとDockerが主流になる前に始まりました。私たちの最初のアプローチは、cgroupsとLinuxコンテナに基づくものでしたが、KubernetesとDockerが市場に定着するにつれ、初期の設計をピボットする必要性が次第に高まってきました。ACNは、クラウドネイティブ、Kubernetesネイティブのプラットフォームとして、ゼロから設計することにしたのです。
1年半の開発期間を経て、2021年3月、私の小さなブログであるdri.esはACNに移行した最初のサイトとなりました。私のサイトが本番稼動したことは、私たちのチームにとって楽しい奮起の場となりました。私のサイトは、以前のAcquia Hostingでローンチした最初のサイトでもあったのでなおさらです。
私は今までACNについてブログを書いたことはありませんでした(お客様のサイトが十分にアップグレードされるまで待ちたかったのです)。それから1年半が経ち、多くのお客様がACNを利用しています。現在では、トラフィック量の多いお客様のサイトもACNで安定して稼働しています。ACNは、アクイアのお客様が信頼する最高レベルのパフォーマンス、自己回復、および動的スケーリングを提供していると、私は疑いなく言えます。
ACNは、アプリケーションのパフォーマンスを継続的に監視し、障害を検出し、トラフィックを迂回させ、人手を介さずにWebサイトを自動的に拡張します。ACNは何十億ものPVを処理し、大規模なトラフィックの急増にも粛々と対応します。そして何より、私たちは機能のリリースを数週間ではなく数分〜数時間で対応することが可能になりました。
これを可視化するには、グラフを共有することに勝るものはありません。
これは、主要サイトをAcquia Cloud NextにアップグレードしたFortune 2000の大企業顧客のWebトランザクション時間です。Acquia Cloud Nextへの移行後、PHP（青い部分）、MySQL（濃い黄色の部分）、Memcached（薄い黄色）が大幅に高速化され、かつ低揮発性になったことがわかります。（グラフはNew Relicによって生成されたものです。New Relicでは、アプリケーションがHTTPリクエストを受け取ってからHTTPレスポンスが送信されるまでの時間を「Webトランザクション時間」と定義しています。）
Acquia Cloud Nextを利用するお客様のメリット：
- ページパフォーマンスとWebトランザクション時間の大幅な高速化（上図参照）
- 従来のMySQLサーバと比較して5倍高速化したデータベース
- 高速な動的オートスケーリングと高速な自己回復
- リソースの分離が改善：Nginx、Memcached、Cron、その他のサービスはすべて専用ポッドで実行されます。
これらの結果を達成するために、私たちはパートナーであるAWSと密接に協力し、Amazon Elastic File System(EFS)、Amazon Elastic Kubernetes Service(EKS)、Amazon AuroraなどのAWSサービスの限界に挑んだのです。例えば、AWSは私たちが成長する規模に対応できるようにEKSに変更を加えた程です。15年間AWSと仕事をしてきて、AWSが私たちのパートナーとして我々の要求に応えようとする姿勢にいつも感銘を受けています。
その過程で、我々のスケーリングの課題を克服するためにAWSはKubernetesのアップストリームに貢献を行いました。これらは、Kubernetesのスピードと安定性を向上させるのに役立ちました。AWSが我々の価値観とオープンソースへのコミットメントを共有していることを私たちは高く評価しています。
最後になりましたが、アクイアの製品、アーキテクト、エンジニアリングの各チームに大きな賞賛を送らないわけにはいかないでしょう。大規模でミッションクリティカルなWebサイトを実行している何万ものEC2インスタンスを持つプラットフォームを再構築することは、並大抵のことではありません。
私たちのチームは、Drupalのための最高のプラットフォームを構築するために、創造的で最先端の方法を探し続けました。その一端を、KubeCon 2022で行ったプレゼンテーションでご覧ください。私たちは、スケーリングの指標をKubernetesの組み込みCPU使用率からカスタム指標に切り替えることで、クラスタのチャーンを〜1,000%削減できることを会得しました。
この3年余りのACNの歩みを振り返ると、ここまで来られたことを、私はとても誇りに思います。
共同設立者 兼 CTO Acquia