BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース DropboxがマネージドサービスオーケストレーションプラットフォームのAtlasを公開

DropboxがマネージドサービスオーケストレーションプラットフォームのAtlasを公開

原文(投稿日:2021/03/10)へのリンク

先日のブログ記事でDropboxが公開したAtlasは、サービス指向アーキテクチャのさまざまなメリットを提供すると同時に、サービスを所有する運用コストを最小限にすることを目的とするプラットフォームである。

Atlasの目標は、小規模かつ自己完結型の機能をサポートすることによって、容量計画や警告のセットアップといった、本格的なサービスを管理するオーバーヘッドからプロダクトチームを救済することにある。Atlasはユーザに、AWS Fargateなどのサーバレスシステムのエクスペリエンスと、自動でプロビジョニングされるサービスによるバックグラウンド支援とを合わせて提供する。作者であるNaphat Sanguansin、Utsav Shah両氏によれば、プラットフォーム運用に際して既製のソリューションの評価も行ったのだが、マイグレーションのリスクを低減し、エンジニアリングコストを抑えるために、Dropboxの他所で使用されているものと同じデプロイメント用オーケストレーションプラットフォーム上で引き続きサービスをホストすることに決定した、ということである。

Atlasを開発した理由は、Dropboxの中心にあるPythonのモノリスであるMetaserverのリプレースだ。開発は複数年を要する作業となり、現在もなお進行中である。現時点において、リプレース対象であるモノリスのトラフィックの25パーセント以上をAtlasが処理している。このマイグレーションプロセスを通じて、作者らは、ある重要な結論を導き出した。

この数年間の開発から得たひとつの重要な結論は、プロジェクトのライフサイクルの早期において、コード構成を十分に検討することが不可欠である、ということです。そうしなければ、技術的負債や複雑なコードが、あっという間に積み上がります。インポートサイクルを解体し、Metaserverを分解する作業は、(...)プロジェクトの戦略上、おそらく最も効果的な部分であったと思います。これによって、新たなコードが問題の原因となることを防止すると同時に、コードが単純で分かりやすいものになったからです。

Metaserverの改良には、それまでも多くの努力が払われていたのだが、コードベースのサイズと複雑さのため、いずれも成功を収めることができなかった、と作者らは述べている。そこで今回のAtlasの実行プランは、マイルストーン(標石)ではなくステップストーン(踏み石)を念頭に置いてデザインされた。つまり、インクリメンタルな各ステップでも十分な価値を提供できるようにすることで、プロジェクトが何らかの理由によって次のステップで失敗した場合に備えたのだ。この戦略の重要な例のひとつとして、モノリシックなコードを改良する作業が挙げられる。この作業には、Atlasの実装とは関係なく、それ自体に実施する価値がある。さらにチームは、Atlasで開発された拡張機能の多くをMetaserverにバックポートすることで、プロジェクトの価値をより高くすることにも成功した。


Atlas以前と以後
出典: https://dropbox.tech/infrastructure/atlas--our-journey-from-a-python-monolith-to-a-managed-platform

Atlasの設計には、コンポーネント化、オーケストレーション、運用可能化(operationalization)を中心とする重要な取り組みが関わっている。Atlasには、コンポーネント化を進めるために、HTTPルートのアトミックな論理グループとしてAtlassservlet("atlas servlets"と読む)が導入されている。作者らによると、"Atlasの準備作業として、MetaserverのすべてのルートをAtlasservletに割り当てる作業をプロダクトチームとともに実施した結果が、5,000以上のルートを対象とする200以上のAtlasservletになった"という。 サーブレットには、それを管理する唯一のオーソリティとして、それぞれにオーナが割り当てられている。さらに、Metaserverのコードベースの分解には、Pythonのインポートサイクルのほとんどを断ち切る必要があった。このプロセスは完遂に数年を要したが、最終的にはBazelビルドシステムとその可視性ルールを適用することによって、レグレッションや新たなインポートサイクルの発生を回避することが可能になった。

オーケストレーション改善のため、Atlasの各サーブレットは独自のクラスタを所持している。この決定によって分離がデフォルトになり、不正なルーティングの影響範囲を同じAtlasservlet内のルートに限定することができると同時に、コードの独立的なプッシュも可能になる。さらにDropboxは、gRPCの標準化も決定した。HTTPトラフィックの処理を継続するためには、同社がサーブレットの前段階でプロキシおよびロードバランサとして使用しているEnvoyが標準で提供する、gRPC-JSONトランスコーディングを使用した。


HTTPトランスコーディング
出典: https://dropbox.tech/infrastructure/atlas--our-journey-from-a-python-monolith-to-a-managed-platform

運用可能化に関して作者らは、"Atlasの隠し味(secret sauce)はマネージドエクスペリエンス"だ、と述べている。この取り組みの大きな柱になっているのが、プッシュされた個々のコードが運用に到達する前に自動チェックを行う自動カナリア分析(automated canary analysis)と、容量計画をほぼ不要なものにする自動スケール機能の2つである。


カナリア分析
出典: https://dropbox.tech/infrastructure/atlas--our-journey-from-a-python-monolith-to-a-managed-platform

この記事に星をつける

おすすめ度
スタイル

特集コンテンツ一覧

BT