スマートにスケールし、コストを抑える: オレクサンドル・レオンハルトとDashDevsがAWSでクラウドインフラを変革した方法

オレクサンドル・レオンハルトが彼のクラウドインフラキャリアの転機を迎えたプロジェクトを振り返るとき、彼はサーバーやアーキテクチャについてだけ話すのではありません。彼は勢いについて話します — 製品のために、クライアントのために、そしてビジネス自体のために。

当時、オレクサンドルはDashDevsのエンジニアリングチームの一員であり、IT企業向けに特化したビジネスプロセスマネジメントの内部プラットフォームを構築していました。

アイデアはシンプルでした: 組織にワークフローを自動化し、オペレーションを可視化し、内部の調整を改善する方法を提供すること。しかし、プラットフォームが成熟し、クライアントの関心が高まるにつれて、既存のインフラがプレッシャーに対応する準備ができていないことが明らかになりました — 財政的にも技術的にも。

「私たちは壁にぶつかり始めていました」とオレクサンドルは言います。「インフラは維持するのが高価で、特にユーザーベースが増え、データ負荷が増加するにつれて。私たちのコンピュートコストは予測不可能で、システムの安定性を維持するために多くのエンジニアリング時間を費やしました。」

会社がスケールするにつれて、これはさらに大きな問題になると認識したオレクサンドルは、クラウド戦略の完全な評価を提案しました。目標は、コスト効率、スケーラビリティ、開発のスピードを考慮してシステムを再設計することでした。

チームは、オーバーヘッドを削減し、インフラコストを常に増加させることなく成長できるように、インフラをAmazon Web Services (AWS)に移行することを決定しました。

最初のステップは、最もリソースを消費するコンポーネントであるデータベースに取り組むことでした。これらをAmazon RDSに移動することで、チームは自動バックアップ、簡単なスケーリング、管理されたセキュリティパッチを得ました。

これにより、以前は手動で行っていた作業の多くが排除され、時間が節約され、人為的エラーのリスクが減少しました。「RDSを使うことで、私たちはAWSに基本的なメンテナンスを任せることができました」とオレクサンドルは説明します。「それはすぐに私たちの運用負担を軽減しました。」

次に、チームはコンピュート戦略に取り組みました。需要に関係なく静的な数の仮想マシンを稼働させるのではなく、EC2インスタンスのオートスケーリングを実装しました。

これにより、システムはリアルタイムのトラフィックに基づいて稼働中のサーバーの数を自動的に調整できるようになり、リソースは必要なときだけ使用されることが保証されました。これにより、オフピーク時に不必要なコストをかけることなく、ユーザー活動のピークと谷を平滑化するのに役立ちました。

しかし、最も重要な変革は、チームがAWS LambdaとAWS Fargateを介してサーバーレスコンピューティングを統合し始めたときに起こりました。特定のワークロードをLambda関数に移動することで、アイドルサーバーのコストを完全に排除することができました。

従来のサーバーベースのモデルからファンクション・アズ・ア・サービスのアプローチへのこの移行は、リクエストを待ってアイドル状態のサーバーに対してではなく、実際の実行時間に対してのみ支払うことを意味しました。

「Lambdaは私たちのスケーリングに対する考え方を根本的に変えました」とオレクサンドルは言います。「私たちはもはや事前に必要なサーバーの数を見積もる必要がありませんでした。代わりに、自動的かつコスト効率よくスケールできるサービスを構築しました。」

しかし、アプリケーションをサーバーレスに適応させるには、技術的なシフト以上のものが必要でした — 開発に対する新しいアプローチが求められました。

プロセスを加速し、各クライアントの適応のために再設計を避けるために、DashDevsチームはAWSサービスの上に独自の内部フレームワークを作成しました。

このフレームワークにより、彼らは新しい機能やワークフローを迅速に開発および展開できるようになり、それぞれがモジュラーなLambda関数として構築されました。

「フレームワークを使うことで、私たちは数ヶ月ではなく数週間で新しい機能を展開できました」とオレクサンドルは指摘します。「それは大きな利点でした、特にクライアントがカスタマイズや新しい機能を要求したときに。私たちは競合他社よりも早く対応でき、開発コストも大幅に削減できました。」

プラットフォームを内部で証明した後、DashDevsは他の企業に提供を開始し、各クライアントのユニークなビジネスプロセスに合わせてソリューションを適応させました。

フレームワークのモジュラー設計のおかげで、各展開は前回よりも迅速かつコスト効率的でした。この適応性により、最初のインフラアップグレードがDashDevsの新しい収益源に変わりました。

再設計プロセス中、チームは特にクラウドプロバイダー間でのインフラストラクチャ・アズ・コードの柔軟性を考慮して、Terraformを使用するかどうかを評価しました。

強力ではありますが、Terraformの広範な範囲は、彼らのAWS中心のスタックには必要のない複雑さを伴いました。

代わりに、彼らはAWSサービスとの統合がより密接で、新しいエンジニアのオンボーディングを簡素化するAWS CloudFormationを選択しました。

「CloudFormationは、Terraformに伴う追加のオーバーヘッドなしで、私たちが必要とするすべてを提供してくれました」とオレクサンドルは言います。「それは私たちの展開を合理化し、チームの学習曲線を減少させました。私たちの目標にとって、そのトレードオフは理にかなっていました。」

もちろん、サーバーレスとオートスケーリングへの移行は課題がなかったわけではありません。チームは、特にテストフェーズ中に突然のリクエストの急増がシステムを設定された閾値を超える可能性があるため、AWS Lambdaの同時実行制限に直面しました。

監視と調整が重要になりました。Amazon CloudWatchを使用して、関数のパフォーマンス、メモリ使用量、実行時間を追跡し、速度とコストの最適化のために設定を調整しました。

財務管理を厳密に保つために、彼らはAWS Cost Explorerと詳細なタグ付けシステムを実装し、さまざまなサービス、環境、クライアントプロジェクトのコストを監視しました。

この可視性は、予算編成だけでなく、インフラの継続的な改善を行うためにも不可欠でした。

最終的に、結果は明らかでした。DashDevsはインフラコストを25%削減し、より迅速で信頼性の高い製品を提供し、新しいクライアント向けのソリューションをカスタマイズするために必要な時間を大幅に短縮しました。

おそらく、より重要なのは、チームがインフラの火消しではなく、製品の革新に集中するための帯域幅を取り戻したことです。

「私たちは単にコストを削減したわけではありません」とオレクサンドルは振り返ります。「私たちは、技術的にも商業的にもスケールすることを可能にするシステムを作りました。

AWSサービスと私たちの内部フレームワークの組み合わせにより、私たちはより速く、より少ない費用で、先を行くことができました。」

今日、その作業は引き続き利益をもたらしています。オレクサンドルが再設計を手伝ったプラットフォームは、DashDevsチームが築いた基盤のおかげで、各クライアントソリューションの基盤となり、各々が特化しつつもコスト効率的です。

「インフラを構築するとき、あなたは単に今日の問題を解決しているわけではありません」と彼は言います。「あなたは、運用コストに縛られることなく成長する会社の能力を設定しています。それがAWSが私たちに可能にしてくれたことであり、私が取り組むすべてのプロジェクトに持ち込むアプローチです。」

*このストーリーは2022年9月3日に最初に公開されました。