進化するアーキテクチャシリーズ、第 3 部

「月へ🚀」

「進化するアーキテクチャ」は、企業がスタートアップライフサイクルのさまざまな段階を経るにつれて、ソリューションの設計と意思決定がどのように進化するかを示す 4 部構成のブログシリーズです。このシリーズでは、ファンタジースポーツリーグに似た「ファンタジー株式市場」アプリケーションを作成することを構想している、その名も Example Startup というスタートアップの例を紹介します。彼らは、1 年間に 4 回の「トーナメント」を開催することを構想しています。

ブログ第 2 部では、創設者が資金調達の準備をしている間に、スタートアップがどのように技術的ソリューションを進化させ始めたかを説明しました。第 3 部では、Example Startup がどのように技術スタックを成熟させ、規模拡大に向けてうまく位置づけるかをご覧ください。

マイクロサービスアーキテクチャへの移行による効率的なスケーリング

ファンタジー株取引チームは成長を続けており、新しいコンポーネントとソリューションが構築されています。技術ポートフォリオが拡大するにつれて、チームの注意を必要とする亀裂が生じ始めています。

「古い習慣はなかなか消えない」と、チームはこれがスタートアップの成長にどのような問題を引き起こす可能性があるかを理解し始めます。厳しいスケジュールと、より少ない労力でより多くのことを成し遂げたいという熱意が、技術的負債の増加につながっています。この技術的負債の一つの側面は、チームが当初決定していたマイクロサービスアーキテクチャとは対照的に、モノリスが徐々に急増していることです。スケーラビリティやパフォーマンスのボトルネックといったモノリスの懸念は、テスト中や新機能の導入中に明らかになり始めています。幸い、チームはこのモノリシックなアプローチがワークロードの最適なスケーリングにもたらす課題をすぐに認識しました。彼らは一歩下がって開発手法を再評価することにしました。あるデベロッパーは、AWS ソリューションアーキテクト (SA) が以前の会話でこれらの問題のいくつかを予測していたことを思い出しました。Example Startup チームは、支援を求めるために AWS との電話をスケジュールしています。

モノリスの解体とマイクロサービスベースのパラダイムへの移行は幅広いトピックであるため、AWS SA は Example Startup のチームにアプリケーションモダナイゼーションのイマージョンデーを設けることを推奨しています。このイマージョンデイでは、関連するワークショップを背景に、スタートアップに関連するワークロードに焦点を当てます。このイベントには会社のほぼすべてのデベロッパーが参加し、最終的には流れを変えるものとなりました。チームは 1 日のうちに、マイクロサービスを適切に定義、設計、実装する方法を学ぶことができます。また、すべてを一度にやり直すことなく、モノリスアプリケーションから一連のマイクロサービスに段階的に移行する方法についても学びます。チームは早い段階で間違いを発見し、今後の助けとなるベストプラクティスを学べることを嬉しく思います。ソリューションアーキテクトは、Example Startup チームの知識不足を埋めることができるモダナイゼーション戦略に焦点を当てた AWS ホワイトペーパーも共有しています。

アプリのモダナイゼーションの経験は Example Startup に大きな価値をもたらし、チームは今後も、さまざまな機能分野に既存のベストプラクティスを活用するという同じアプローチを適用することにしました。エンジニアとプロダクトマネージャーは、作業の重複を避けるため、今年の残りの期間のロードマップを AWS と共有する電話会議を予定しています。Example Startup はすでに AWS と相互秘密保持契約 (MNDA) を締結しており、この会話の中で双方が生産的に自由にアイデアを出し合いました。また、素晴らしいニュースもあります。Example Startup が自社で構築を検討していた機能が、すでに AWS の次の四半期のロードマップに含まれていることが判明しました。これにより、チームのエンジニアリングの時間を大幅に節約できました。

Example Startup の改善すべき分野のリストの次のトピックは、Infrastructure as Code (IaC)、継続的インテグレーションと継続的デリバリー (CI/CD)、および自動テストに関するものです。新たに採用された 2 人のデベロッパー運用 (DevOps) 担当者は、スタートアップにおける現在の運用メカニズムの多く、特に環境の構築やテスト、コードアーティファクトの管理などに満足していません。Example Startup のチームが拡大しているということは、これらの機密性の高いプロセスにアクセスできる人が増えるということであり、不必要なリスクが生じているということです。この 2 人の新しいチームメンバーは、すでに IaC へのアプローチとして Terraform を使った経験があります。彼らは、AWS が Terraform によって十分にサポートされていることを知り、代替手段が必要な場合に備えて AWS CloudFormation や AWS CDK などの他のツールを利用できることを嬉しく思っています。ただし、CI/CD のセットアップに関してはまだある程度の支援が必要です。彼らの試みはこれまでのところまとまりがなく、構築されたツールをデプロイメントツールとうまく連携させるのは難しいことがわかっています。さらに、コンテナイメージを管理するための適切なアプローチを模索しているところです。AWS チームは、AWS CodePipeline の検討を推奨しています。AWS CodePipeline はビルドとデプロイツールをシームレスに統合したいというニーズを満たし、自動テスト機能も備えているため、さまざまな環境をサポートしているからです。CodePipeline を使用すると、AWS ネイティブで構築されたものではないソリューションとの統合が可能になるだけでなく、AWS CodeBuild、AWS CodeDeploy、サードパーティツールなどの他のツールを強力にサポートできます。CodePipeline を実装することで、Example Startup はリスト内のもう一つの大きな項目をチェックできるようになります。

チームがマイクロサービスの適切な実装に向けて順調に進んでいることで、彼らは未解決のままになっている他の複雑な課題に取り組む余力を与えられていると感じています。第一に、複数のサービスが独立して動作していると、当然ながらこれらのサービス間の通信の問題が浮かび上がってきます。チームがパブリッシュ/サブスクライブ (PubSub) メッセージングなどのベストプラクティスパターンをどのように採用できるかということに加えて、すべてのクロスサービス呼び出しの通信を同期と非同期のどちらにするかという点には大きな疑問点があります。チームは、特にモノリスからの移行において、イベント主導型アーキテクチャを採用することが有益であることを広く理解していますが、Amazon EventBridge、Amazon Simple Queue Service (Amazon SQS)、Amazon Simple Notification Service (Amazon SNS)、Amazon Managed Streaming for Apache Kafka (Amazon MSK) など (ただしこれらに限定されません)、そのアーキテクチャに関連する AWS サービスの数に少し圧倒されています。今回は、このトピックに関する非常に有益なワークショップやブログなど、素晴らしい出発点となるリソースをチーム自身が見つけることができました。「イベント主導型」のパラダイムは、徐々にチームのツールボックスのもう一つのツールになりつつあります。

より強力なセキュリティ戦略の開発

セキュリティは、スタートアップにとって引き続き最優先事項であり、AWS スタートアップセキュリティベースライン (AWS SSB) などのツールはスタートアップを始動するのに役立ちます。残念なことに、セキュリティはいくら強化しても足りません。AWS WAF の初期実装は良いスタートでしたが、チームは防止、検出、修復についてより積極的に考え始める必要があります。強力なセキュリティ戦略の導入に役立つ、セキュリティに重点を置いた多くの AWS サービスのスキルを磨き始めています。

チームが拡大し、パートナーとの関与も増えたことで、アクセス制御、権限、ガバナンスなど、注力すべきトピックが増えています。チームは、権限を適用する際の最小権限の原則などのベストプラクティスを実装しようとしています。少なくとも、本番環境のワークロードをそれぞれ別のアカウントに移動したいと考えています。チームがこれらのベストプラクティスを採用するにつれ、対処しなければならない管理と権限のレイヤーが増えるため、運用が複雑になることに気付きました。アカウント構造には機械化されたアプローチが必要であることが急速に明らかになりました。誰かが AWS Organizations について言及し、これは正しい方向への一歩のように思えたため、信頼できる AWS SA にチャットをするために連絡をしました。SA は、複数のアカウントと AWS 組織を管理するためのより簡単なアプローチとして AWS Control Tower を検討するなど、関連するアドバイスをいくつか共有しています。これは、強固なマルチアカウント戦略を実現するための多くのステップのうちの最初のステップであるため、AWS SA は「複数の AWS アカウントへの移行」の規範的ガイダンスもチームと共有しました。このガイドには、複数アカウントの設定に移行する際のアカウント移行、ユーザー管理、ネットワーク、セキュリティ、アーキテクチャに関するベストプラクティスが記載されています。

パフォーマンス向上のためのワークロードの最適化

スタートアップが適切なペースで成長するため、チームはいくつかの基礎的な要素に取り組んでいます。リストから削除された主要項目もあれば、アクションプランが策定された項目もあります。デベロッパーは、パフォーマンスを考慮してワークロードを最適化するためにできる限りのことを行っていますが、Amazon CloudFront によるエッジキャッシュ、Amazon ElastiCache によるアプリケーションレベルでのキャッシュ、データベースキャッシュなど、コード以外のさらなる改善の機会もいくつか特定しています。チームは、関連する運用の複雑さを最小限に抑えながら、必要な機能を提供するために AWS マネージドサービスへの依存度が高まっています。何人かのデベロッパーが、驚くほど使いやすいと感じているマネージドサービスの 1 つが AWS Batch です。AWS Lambda による初期のフィード処理アプローチは、処理が必要なデータ量が急激に増加しているため、限界に達し始めています。いくつか実験を重ねた結果、デベロッパーは AWS Batch を使用するまでの道筋を描くことができました。これにより、運用上の負担をほとんど増やさず、コストを低く抑えながら成長を続けることができます。

スタートアップの価値提案の証明

Example Startup でのこの素晴らしい仕事は、すべて気付かれないわけではありません。短期的な回避策に頼ることなく、俊敏かつ持続可能な方法で構築することは、その企業が長期的なことを考えており、成熟度を示し、成果を出す能力を備えていることを示しています。これらの特性は、革新的なソリューションと優れた製品市場適合性とともに、会社の価値提案の中核を成すものです。創設者たちは自社の価値をいくつかの異なるベンチャーキャピタル企業にうまく伝え、最初のシリーズ A の資金調達ラウンドを締めくくりました。Example Startup は月面に向かっています。

進化するアーキテクチャシリーズブログの第 1 部および第 2 部をご覧ください。