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

「ご一緒にコーヒーはいかがですか?」

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

ブログ第 3 部では、スタートアップがどのようにしてアーキテクチャを CI/CD パイプラインや Infrastructure-as-Code などのツールを含むものに進化させ、特にセキュリティと認証に関するベストプラクティスを実装し始めたかを説明しました。第 4 部では、Example Startup がさまざまなコンプライアンス基準を満たすためにセキュリティとバックアップの態勢を正式化していきます。また、組織のデータ戦略を立て、製品ポートフォリオを多様化するために他事業分野も検討していきます。

シリーズ B の資金を使用した、雇用、拡大、スケーリング

Example Startup にとって、できる限りで物事は順調に進んでいます。彼らは最近、採用、拡大、およびスケーリングを促進するためのシリーズ B の資金調達ラウンドを終了しました。資金調達と顧客導入に伴い、競争も激化しています。この分野で定評のあるプレーヤーは、彼らを真剣な競争相手と見なし始めており、マーケティング活動を強化しています。

Example Startup は、機能分野を拡大し、サイト信頼性エンジニアリング (SRE)、プラットフォーム、分析、データサイエンスの専門チームを作るために採用を開始しました。競争の激しい労働市場と、スタートアップには専任の人事部門がないことから、彼らは再び AWS アカウントチームに連絡して、AWS に精通した技術者の発掘について尋ねます。彼らは、採用ニーズを支援する AWS パートナーを提案することで、同じような状況にある他のスタートアップ顧客をアカウントチームが支援してきたと知りました。間もなく、受信箱には、AWS の経験を持つ複数の審査済み候補者からのメールが届きます。幸いにも、面接の多くは内定に変わり、スタートアップは To-Do リストから採用を外すことができました。

採用は技術的な問題につながります。Example Startup のプラットフォームチームがテスト目的で新アカウントを設定するのに時間がかかりすぎて、イノベーションが阻害されているという不満がチームから寄せられています。プラットフォームチームは、誰かが新しい機能のアイデアを思いついたときに、いつでも個別のアカウントを構築するような余裕はないと説明しています。AWS 導入のこの時点で、プラットフォームチームは AWS アカウントチームと 2 週間に一度ミーティングを開き、ジレンマを提起します。AWS ソリューションアーキテクト (SA) は、AWS の組織内にサンドボックス専用の組織単位 (OU) を設置して、AWS の新しいサービスや機能をテストしたい他のチームに一時的なリソースや環境を迅速にプロビジョニングすることを推奨しています。さらに、コストを抑えるために、SA は自動化を使用して Amazon EC2 インスタンスなどのリソースを通常の営業時間外に自動的に停止することを推奨しています。Example Startup のプラットフォームチームは SA のアドバイスに従います。そうすることで、スタートアップ全体のさまざまなチームのアカウントを、コストを抑えながらすばやく立ち上げることができるようになりました。

これに続いて、新たに採用された SRE チームは、スタートアップが可用性とディザスタリカバリ (DR) の観点からより有利な立場に立つことができることに気づきました。彼らは、スタートアップが急速に成長し、大規模な顧客をターゲットにし始めると、監査やコンプライアンスレビューなどで、より厳しいセキュリティ要件に直面することになると認識しています。そのため、インフラストラクチャをある程度変更する必要が生じます。幸いなことに、このシリーズの第 3 部で Example Startup は、インフラストラクチャを Terraform にテンプレート化し、マルチアカウントアーキテクチャーに移行しており、ディザスタリカバリに伴う重大な負担については解消していました。

最初のステップとして、Example Startup チームは AWS Resilience Hub に慣れ、耐障害性のあるアプリケーションを AWS で構築する方法について詳しく学びます。チームにはまだ未解決の質問がいくつかあるので、AWS アカウントチームに連絡して、耐障害性に関する専門知識を持つ SA を紹介してもらいます。SA は Example Startup と協力して、目標復旧時間 (RTO) と目標復旧時点 (RPO) の要件を特定し、さまざまなディザスタリカバリシナリオの費用対効果分析を行います。SA と何度か電話をし、社内で多くの審議を行った結果、SRE チームは、RTO/RPO 要件では現時点ではマルチリージョンの設定は必要ないと判断しました。彼らは、トランザクションデータを Amazon RDS for PostgreSQL から Amazon Aurora for PostgreSQL に移行することを決定しました。これは主に、可用性が高いことと、本番データベースにとって重要な Amazon Aurora Global Database 機能を利用できるようにするためです。また、このスタートアップは AWS Audit Manager を使用して、今後の監査に関連するコンプライアンス基準への準拠状況を評価しています。これにより、自動エビデンス収集機能により、手作業による労力を大幅に削減できます。

より良いカスタマーエクスペリエンスの構築

さまざまな顧客からの製品フィードバックをふるいにかけた結果、最高技術責任者 (CTO) は、Example Startup の取引アプリケーションでトレーダーに提供されるダッシュボード機能が不足していることに気付きました。競合他社は、(他のトレーダーと比較して) 取引履歴とパフォーマンスを取引レベルごとに視覚的に簡単に確認できるようにしています。CTO はこれを重要な機能ギャップとして指摘し、その作業は新しい分析チームに割り当てられました。さらに、CTO は、トレーダーが自由に取引レポートを作成できるようにすることを要求しています。

分析チームは過去に Amazon Quicksight を使用したことがあり、ダッシュボードコンポーネントは簡単に拡張できます。これには、トレーダーが外れ値である特定の取引を見つけるのに役立つ異常検出機能が含まれます。レポートの要求はより複雑です。というのも、レポートを運用データベースで実行してデベロッパーチームを混乱することは避けたいためです (これは良い方法とは見なされません)。AWS のモダンデータアーキテクチャのホワイトペーパーを調べた結果、分析チームは、これを実現する最善の方法は、Amazon RDS for PostgreSQL をデータウェアハウスである Amazon Redshift にロードすることだと気づきました。Amazon Redshift の大規模な並列処理を使用することで、このトランザクションデータに対して複雑な集計をはるかに少ないレイテンシーで実行できるようになり、さらに本稼働データベースのボトルネックにならないという利点もあります。Amazon Redshift は PostgreSQL エンジンをベースに構築されているため、ほとんどのクエリを再利用できることに分析チームは喜んでいます。

スタートアップに新しい事業分野を追加

こうした変化が起こる中、最高経営責任者 (CEO) は大手商社の元同僚との会議に出席します。彼女は、市場には有能なトレーダーが不足しており、これが取引会社の雇用パイプラインと将来のプロジェクトに悪影響を及ぼしていることを知りました。CEO は商社の友人数人に電話をかけ、これが業界全体で不足していることを確認しました。CEO はあるアイデアを練り始めます。例えば、スタートアップには、業績の良いトレーダーがたくさんいます。Example Startup がトレーダーに何らかのコホートベースのトレーニングを提供し、それがこれらの商社の雇用パイプラインにつながるとしたらどうなるでしょうか?そうすれば、トレーダーは雇用市場に参入する機会が得られ、商社は新しい人材を獲得できるでしょう。

トレーニングの重要な部分は、新たなトレーニーに正しい取引を勧めることであるため、CEO はデータサイエンスチームと電話をし、機械学習 (ML) モデルをどれだけ迅速に構築できるかを調べます。幸い、データサイエンスチームの中には、Amazon Sagemaker でモデルの構築、トレーニング、デプロイの経験がある者もいます。Amazon Redshift は SageMaker で使用できるデータソースの 1 つなので、データサイエンスチームは複雑な抽出、変換、ロード (ETL) パイプラインをセットアップする必要はありません。SageMaker の使用経験が浅いデータサイエンスチームのメンバーは、すぐにスキルアップできるように、AWS アカウントチームから SageMaker に焦点を当てたイマージョンデーに招待されました。すぐに、彼らもトレーニングジョブの作成、正確なモデルの構築、エンドポイントへのモデルのデプロイに取り掛かりました。データサイエンスチームは、Example Startup の財務チームから計算コストの増加に関する電話がかかってくるのを見越して、ある調査を行った結果、トレーニングジョブ (総コストの約 80% を占める) をスポットインスタンスで実行できることがわかりました。これにより、コストを大幅に削減することができました。

新事業分野および収益源としてのこの人材開発イニシアチブのニュースが業界に広まるにつれ、スタートアップが次の資金調達ラウンドを開始する意向を表明する前から、より多くのベンチャーキャピタル (VC) 企業が Example Startup に関心を示し始めました。

数四半期後、マーケティング活動、AWS との共同マーケティング活動、および既存の顧客からの口コミに導かれ、Example Startup の人材開発イニシアチブは急速に成長しました。顧客ベースの拡大と同じくらいエキサイティングなのは、スタートアップが創業以来初めて黒字になったという事実です。人材紹介はスタートアップにとって収益性の高いビジネスであることが判明し、日を追うごとに成長しています。経営陣は、この安定した収益源が残りの事業の原動力になり得ることを認識しています。彼らは、これからの素晴らしい未来に期待して、さらなる拡大とイノベーションの計画に熱心に取り組んでいます。

まとめ

この 4 部構成のシリーズでは、Example Startup を通して、スタートアップの初期段階から成熟した企業までの主要段階を順を追って説明します。ほとんどのスタートアップは、大胆なアイデアと献身的な創設チームのみでスタートします。彼らは、創設チームが管理可能な方法でアイデアをテストできるサーバーレスインフラストラクチャでを使用して、実用最小限の製品 (MVP) を構築します。

スタートアップが有料顧客を獲得し、シード後の資金を確保するにつれ、「何かに向かい動き始めている」段階に移行します。この段階ではアーキテクチャが進化し、スケーリング、セキュリティ、開発の俊敏性について真剣に考え始めます。つまり、ビルドツールの使用や、監視データベースや専用データベースの設定などの改善が必要だということです。

これらの段階で最も重要な教訓の 1 つは、プロジェクトを開始する前であっても、早い段階で、かつ頻繁に AWS チームと話し合い、選択肢を評価して時間を節約することです。ビジネスリソースと技術リソースの両方にアクセスできると、タイムラインを短縮でき、初期段階のスタートアップチームが目標を達成するのに役立ちます。

製品市場適合段階が過ぎると、スタートアップはより多くの人材を採用し始め、主にスケーリングに注力する、つまり「月へ向かう」段階になります。この時点で、サービス指向のアーキテクチャ、キャッシング、その他のアーキテクチャの調整を使用してアプリケーションを最適化し、技術的な観点からカスタマーエクスペリエンスを向上させるマルチアカウント戦略を検討し始めます。

ついに、彼らは大規模な雇用を開始し、追加の事業分野を構築する可能性のあるハイパースケールの段階に入ります。技術的な観点から見ると、このスタートアップは自社の環境のセキュリティ、制御、権限などの改善に多くの時間とエンジニアリング努力を費やしてきました。彼らはおそらく、迅速な国際展開やディザスタリカバリなどのユースケースに活用できる、体系化された環境を備えています。また、データ戦略を策定し、分析と機械学習を活用して顧客とビジネスをより深く理解している最中です。この最終段階はさまざまです。買収への道を歩んでいるスタートアップもあれば、収益性と市場優位性を追求するスタートアップもあります。

スタートアップを始める準備はできましたか?AWS Activate に参加して、適切なリソースを適切なタイミングで活用してスタートアップを構築し、スケールしましょう。

進化するアーキテクチャシリーズをすべてご覧ください。

• 進化するアーキテクチャ、第 1 部「素晴らしいアイデアが浮かんだ!」
• 進化するアーキテクチャ、第 2 部「私たちは動き始めている」
• 進化するアーキテクチャ、第 3 部「月へ」