BT

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

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース Coinbaseが構築した”運用環境への道” - QCon Plus Q&Aより

Coinbaseが構築した”運用環境への道” - QCon Plus Q&Aより

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

Coinbaseでは、エンジニアと顧客の数が増えるに従って、より多くのプロジェクト、早いイテレーション、増え続けるインフラストラクチャに対する多くのコントロールを必要とするようになった。開発者が何をしているかを見て、それを支援するための社内デプロイメントツールを開発していく過程において、同社は、セルフサービスの文化を構築したのだった。

Coinbaseでインフラストラクチャテクノロジのリーダを務めるGraham Jenson氏は、QCon Plus 2020で、同社が運用環境への道(paved roads to production)を整備していった過程について語った。

Heroku(当初使用していた)上では、コンフィギュレーションの変更、新たなリソースのセットアップ、あるいは新プロジェクトの立ち上げには管理者パネルへのアクセスが必要であったため、その使い方を知らなくてはならなかった。これがプロジェクトの作成とデプロイのブロッカ(blocker)になり、企業をスローダウンさせていた、と氏は言う。"開発者をブロックされた状態から解放して、もっと生産的にしたかったのです"。

デプロイメントをスケールアップするために氏らは、新たなプロジェクトをデプロイする際に開発者が行わなければならないステップをすべて書き上げた。その上でブロックを取り除き、ステップを簡素化することに集中したのだ。

最大のブロックはHerokuでした。では、どのステップでHerokuをリプレースできるのか?それはどのようなもので、開発者たちには、それとどのように対話してほしいのか?開発者にはコンフィギュレーションに対するもっと多くのコントロールと、安全でセキュアなデプロイを支援する構築ツールを提供したいと考えていました。しかし、それをコミットからリリースに移行するためには、具体的にどのようなステップを実行したい/しなければならないのか?そのために、これらのツール、システム、プロセスを構築する必要があったのです。

Coinbaseが望んでいたのは、開発者が自身のコンフィギュレーション、リソース、デプロイメントを管理できるような、セルフサービスの文化の確立だった。セレモニを不要として、極めて安全なデプロイを可能にすることで、開発者に頻繁なデプロイを促したかった、とJenson氏は述べている。そのためには、ユーザビリティに投資し、必要な情報に簡単にアクセスできるようにする必要があった。

Codeflowと呼ばれるデプロイメント用ツールの開発を決定した理由について、Jenson氏は次のように説明している。

Codeflowによって、開発者たちが自らのコードをコミットできるようになりました。コードは自動的にビルドされ、1分以内にデプロイ可能になります。社内開発としたのは当社独自のセキュリティ要件のためですが、Dockerなどの使い慣れたテクノロジを多用して、開発者が簡単に使えるように設計されています。

最も重要なタスクは、開発者が何をしているのかを確認し、それを支援することだ、とJenson氏は指摘する。多くのプロジェクトが複雑化の方向に進んでおり、実際に削除されるものは何もない。さらに悪いのは、誤った問題でさえ修正しようとすることだ。修正すべき問題を見つけ出す明らかな方法のひとつは、何かをデプロイする場合に行っているステップを開発者に聞いて、そこから簡素化と修正を行うことだ、とJenson氏は示唆する。

Graham Jenson氏に、デプロイメントへの道の構築と拡張について話を聞いた。

InfoQ: 運用環境への道(paved roads to production)という概念について説明してください。

Graham Jenson: "道"というのは、コードのコミットから運用環境へのデプロイまで、開発者が実行しなければならないすべてのステップのことです。この道を歩きやすいものにする、すなわち"舗装(pave)"するには、開発者が自身の作業を具現化する過程を遅める、あるいはブロックするステップを見つけ出し、取り除く必要があります。この作業の成果として、イテレーションのペースが向上したと同時に、ある意味矛盾しているのですが、コードをデプロイする場合のリスクも低減しました。

リリースインフラストラクチャを語る言葉として、この"舗装道(paved roads)"というメタファは適切なものだと思います。構築やメンテナンスのコストは高いのですが、運搬は楽になります。それに、道は多くの人が共有するものなので、メリットも大きいのです。

InfoQ: Coinbaseがスタートした頃、デプロイメントの"道"はどのようなものでしたか?

Jenson: Coinbaseの初期には、デプロイメントにプラットフォーム・アズ・ア・サービス(PaaS)のHerokuを使っていました。デプロイメントの複雑な部分はほとんどこれが処理してくれるので、"git push"を使うのと同じくらい簡単に行うことができました。アプリケーションは、"Heroku"アプリケーションに求められる仕様に一致するように、一般的には"The Twelve-Factor App"ガイドラインに沿って構築することになります。その上で管理パネルを使って、データストアや環境変数、セキュリティなど、アプリケーションの設定を行います。後はリモートブランチに"git push"すればデプロイされるのです。

開発者が少ない間はこれでうまく行っていたのですが、企業が成長するにつれてデプロイメントに問題が生じました。

InfoQ: プロジェクトの数が増えたことで、どのような問題に直面したのでしょうか?それらには、どのように対処しましたか?

Jenson: 私が入社してからの5年間、Coinbaseは常に成長を続けてきました。プロジェクトの数とエンジニアの数がいずれも増えているので、デプロイパイプラインはいつもどこかの場所で拡張されています。ですが、開発者が何をしているのかを見て、タスクの自動化あるいは単純化を試みる、という私たちの方針に変わりはありません。

最近あった問題は、複数のリポジトリにまたがるプロジェクトの数が拡大し、運用が難しくなってきたことです。些細なアップグレードでも、数千というプロジェクトをアップデートしなければならず、大きな労力を必要としていました。これを契機として、巨大な単一のリポジトリにすべてのプロジェクトを収容することで、1回のコミットでアトミックに変更を行うことができるという、モノレポ(monorepo)を作成することになったのです。この結果、企業全体にとって基本的なコンポーネントをアップデートする場合でも、開発者が実行する必要のあるステップの数は非常に少なくなりました。

InfoQ: Codeflowという独自のデプロイメントツールを開発していますが、これは何をするものなのでしょう? また、HerokuからCodeflowへのマイグレーションはどのように行ったのですか?

Jenson: Codeflowは、Herokuをリプレースするために私たちが開発した、開発者が自分たちのプロジェクトを構成し、クラウドにデプロイするためのセルフサービスツールです。すべてのプロジェクトをCodeflowに収めることで、投資すべき舗装道(paved road)をひとつにして、企業スケールの改善を実現するのが目標です。

HerokuからCodeflowへの移行には不安がありました。開発の進め方を大きく変えるだけでなく、当社のメインアプリケーションのHerokuからAWSへのマイグレーションでもあったからです。ですから、何層ものリスクがありました。リスクを軽減するために、実施前、実施中、実施後に何を行うのか、アクションアイテムには誰が責任を負うのか、それぞれのステップで問題が発生した場合にどうするのか、といったことの、長大なリストを作成しました。これらすべてのリストを共有することで、ステークホルダからのインプットを得て、見逃しのないようにすることができたのです。

InfoQ: セルフサービスの文化を作り上げるために、どのようなことをしたのですか?

Jenson: 文化はソフトウェアで作るものではありませんが、ソフトウェアが文化を妨げることはあります。ですから、まず最初にすべきなのは、現時点で文化の拡散を妨げているブロッカを取り除く方法を決めることです。それがつまり、まずHeroku(その時点で重大なブロッカになっていました)をスタックから取り除いて、私たちがコントロールできるものに移行することだったのです。Herokuを排除して、セルフサービス、頻繁なデプロイ、デプロイの大規模化を支援する新たなスイートへの移行ができれば … その後には、これらのツールが有用で信頼できるものであるという、開発者たちの信頼を勝ち取るためのハードワークが控えています。

この記事に星をつける

おすすめ度
スタイル

BT