Oleksandr Leonhard は、クラウド インフラストラクチャのキャリアにおけるターニングポイントとなったプロジェクトを振り返るとき、サーバーやアーキテクチャについてだけ話しているわけではありません。彼は、製品、クライアント、そしてビジネス自体の勢いについて語ります。
当時、Oleksandr は DashDevs のエンジニアリング チームの一員で、IT 企業に合わせたビジネス プロセス管理のための内部プラットフォームを構築していました。
アイデアはシンプルで、ワークフローを自動化し、業務を視覚化し、内部調整を改善する方法を組織に提供することでした。しかし、プラットフォームが成熟し、顧客の関心が高まるにつれて、既存のインフラストラクチャが財政的または技術的にプレッシャーに対処する準備ができていないことが明らかになりました。
「私たちは壁にぶつかり始めていました」とオレクサンドルは言う。 「特にユーザーベースが拡大し、データ負荷が増加するにつれて、インフラストラクチャの維持費が高くつきました。コンピューティングコストは予測不可能であり、負荷がかかった状態でシステムの安定性を維持するためだけに多くのエンジニアリング時間を費やしました。」
Oleksandr 氏は、会社が拡大するにつれてこの問題がさらに大きくなるだろうと認識し、クラウド戦略を完全に評価することを提案しました。目標は、コスト効率、拡張性、開発速度を念頭に置いてシステムを再構築することでした。
広告
チームは、オーバーヘッドを削減し、インフラストラクチャのコストを継続的に増加させることなく成長できるサービスに焦点を当て、インフラストラクチャをアマゾン ウェブ サービス (AWS) に移行することを決定しました。
最初のステップは、最もリソースを多く必要とするコンポーネントであるデータベースに取り組むことでした。これらを Amazon RDS に移行することで、チームは自動バックアップ、簡単なスケーリング、管理されたセキュリティ パッチを利用できるようになりました。
これにより、これまで処理していた手作業の多くが不要になり、時間が節約され、人的ミスのリスクが軽減されました。 「RDS を使用すると、AWS に依存して重要なメンテナンスを処理できるようになります」と Oleksandr 氏は説明します。 「すぐに運用上の負担が軽減されました。」
次に、チームはコンピューティング戦略に目を向けました。需要に関係なく静的な数の仮想マシンを実行し続けるのではなく、EC2 インスタンスに Auto Scaling を実装しました。
広告
これにより、システムはリアルタイムのトラフィックに基づいて実行中のサーバーの数を自動的に調整し、リソースが必要な場合にのみ使用されるようにすることができました。これにより、オフピーク時に不必要なコストが発生することなく、ユーザー アクティビティの山と谷を平滑化することができました。
ただし、最も重要な変革は、チームが AWS Lambda と AWS Fargate を介してサーバーレス コンピューティングを統合し始めたときに起こりました。特定のワークロードを Lambda 関数に移動することで、アイドル状態のサーバーのコストを完全に排除することができました。
従来のサーバーベースのモデルから Function-as-a-Service アプローチへの移行により、アイドル状態でリクエストを待っているサーバーに対して料金が支払われるのではなく、実際の実行時間に対してのみ料金が支払われることになります。
「Lambda は、スケーリングについての考え方を根本的に変えました」と Oleksandr 氏は言います。 「必要なサーバーの数を事前に見積もる必要はなくなりました。その代わりに、自動的かつコスト効率よく拡張できるサービスを構築しました。」
しかし、アプリケーションをサーバーレスに適応させるには、技術的な変化以上に、開発への新しいアプローチが必要でした。
プロセスを高速化し、クライアントの適応ごとに再エンジニアリングを回避するために、DashDevs チームは AWS サービス上に独自の内部フレームワークを作成しました。
続きを読む：OpenAI が ChatGPT に Google Cloud を利用、Microsoft アライアンスと AI インフラストラクチャ競争を激化
広告
このフレームワークにより、新しい機能とワークフローを迅速に開発してデプロイすることができ、それぞれがモジュール式の Lambda 関数として構築されました。
「このフレームワークを使用すると、新しい機能を数か月ではなく数週間で展開できるようになります」と Oleksandr 氏は述べています。 「これは、特にクライアントがカスタマイズや新機能を要求した場合に大きな利点でした。競合他社よりも迅速に対応でき、開発コストも大幅に削減できました。」
社内でプラットフォームを実証した後、DashDevs は他の企業への提供を開始し、各クライアントの独自のビジネス プロセスに合わせてソリューションを適応させました。
フレームワークのモジュール設計のおかげで、すべての導入が前回よりも迅速かつコスト効率が高くなりました。この適応性により、最初のインフラストラクチャのアップグレードが DashDevs の新たな収益源になりました。
再アーキテクチャのプロセス中に、特にクラウド プロバイダー全体にわたるコードとしてのインフラストラクチャの柔軟性を考慮して、チームは Terraform を使用するかどうかも評価しました。
Terraform は強力ですが、範囲が広いため、AWS に重点を置いたスタックには必要のない複雑さが伴いました。
広告
代わりに、AWS CloudFormation を選択しました。これにより、AWS サービスとの統合が強化され、新しいエンジニアのオンボーディングが簡素化されました。
「CloudFormation は、Terraform に伴う追加のオーバーヘッドなしで、必要なものすべてを提供してくれました」と Oleksandr 氏は言います。 「これにより、導入が合理化され、チームの学習曲線が短縮されました。私たちの目標にとって、このトレードオフは理にかなっていました。」
もちろん、サーバーレスと自動スケーリングへの移行には課題がなかったわけではありません。チームは AWS Lambda の同時実行制限に遭遇しました。特にテスト段階で、突然のリクエストのバーストによりシステムが設定されたしきい値を超える可能性がありました。
モニタリングとチューニングが重要になりました。 Amazon CloudWatch を使用して、関数のパフォーマンス、メモリ使用量、実行時間を追跡し、速度とコストの両方を最適化するように設定を調整しました。
財務管理を厳格に保つために、AWS Cost Explorer と詳細なタグ付けシステムを実装して、さまざまなサービス、環境、クライアント プロジェクト全体のコストを監視しました。
この可視性は、予算編成だけでなく、インフラストラクチャを継続的に改善するためにも不可欠でした。
広告
結局のところ、結果は明らかでした。 DashDevs はインフラストラクチャ コストを 25% 削減し、より高速で信頼性の高い製品を提供し、新規顧客向けにソリューションをカスタマイズするのに必要な時間を大幅に短縮しました。
おそらくもっと重要なことは、チームが帯域幅を再利用して、インフラストラクチャの消火活動ではなく製品のイノベーションに集中できるようになったということです。
「単にコストを削減しただけではありません」とオレクサンドル氏は振り返ります。 「私たちは技術的にも商業的にも拡大できるシステムを構築しました。
AWS のサービスと社内フレームワークを組み合わせることで、より迅速に行動し、支出を削減し、時代の先を行くことができました。」
現在もその取り組みは成果を上げ続けています。 Oleksandr がリエンジニアリングに協力したプラットフォームは、DashDevs チームが築いた基礎のおかげで、複数のクライアント ソリューションの基盤となり、それぞれがカスタマイズされながらもコスト効率が高くなります。
「インフラを構築するとき、単に今日の問題を解決するだけではありません」と彼は言います。 「運用コストに囚われずに会社を成長させる能力を確立することになります。それが AWS のおかげで私たちに可能になったことであり、私が取り組むすべてのプロジェクトでこのアプローチを採用しています。」
この記事はもともと 2022 年 9 月 3 日に公開されました。
