私はクラウド アーキテクチャについてはまったくの初心者ですが、アプリケーション開発の経験は十分にあります。現在、Web アプリケーションを介して 5 ～ 10 人のユーザーが大規模な計算パイプラインにアクセスできるようにする作業を行っており、これをすべて AWS で設定しています。
私の現在の実装は、2 つの API と MySQL バックエンドを使用する軽量の React Web アプリです。これにより、ユーザーはパラメーターを使用してジョブをキューに入れ、Web アプリ経由または実行完了後にユーザーに送信される電子メールから最終結果にアクセスできます。
このパイプラインの途中には、これらのステップを計算するために非常に強力なマシン (64 GB の RAM、16 個のコア、1 TB の HDD) を必要とする独自のソフトウェア部分への依存関係があり、この 1 つのステップだけで最大 1.5 日かかることがあります。これがパイプライン全体で最大のボトルネックです。
コストをできるだけ節約するために、複数の EC2 インスタンス「エージェント」をオンにして、手順を実行し、電子メールを送信し、Web アプリのデータベースに書き込み、Web アプリからのアクションによってトリガーされる AWS Lambda 関数を介してインスタンスを停止できるようにすることで、ボトルネック/サービス部分をスケーラブルかつコスト効率の高いものにしようとしています。
この部分の同時実行性/スケーラビリティは非常に小さいため、Web アプリ用に 1 つの EC2 インスタンス、2 つの API、および MySQL サーバーをホストする予定です。また、ボトルネック サービス用に 1 ～ 3 つのインスタンスを用意して、5 ～ 10 人のユーザーからの同時実行を共有し、同時に最大 3 つの重いステップを実行できるようにします。
ボトルネック サービスではプログラムを実行するために同様のファイルが必要であり、これらの手順への入力は 150 GB のファイル サイズになることもあるため、入力の保持に EFS または S3 ストレージを使用することを考えています。そうすれば、入力ファイルを EC2 インスタンス間で共有できる 1 つの場所に転送するだけで済み、転送手順を実行するためにインスタンスが開始されていることを確認する必要がなくなります。これは手動の部分の 1 つであり、ファイル サイズが非常に大きいため、自動化する良い方法もまだわかりません。
私の質問は、私の設定は妥当か、そして私の実装アイデアに欠陥があるかどうかです。現在、サービス インスタンスに EBS ストレージを使用していますが、150 GB の転送/メンテナンスの入力場所を最小限に抑えたいと考えています。また、S3 と EFS はどちらもマルチインスタンス マウント可能なようですが、どちらを使用すればよいのでしょうか。また、サービス インスタンスが完了後にデータベースに書き込めるようにする必要がある場合、Web アプリ、API、データベースを 1 つの EC2 インスタンスに保持しておくのは理にかなっていますか。そのインスタンスは常にオンになります。
ご協力ありがとうございました。また、私が無知なことを言ってしまったらお許しください。
答え1
あなたの設定は妥当なようです。API を「ホスト」する API ゲートウェイを検討し、それがうまくいくかどうか検討してみることをお勧めします。また、負荷の高い EC2 インスタンスを Autoscaling グループに配置し、インスタンスに直接ではなく、制御 Lambda がそのインスタンスと対話するようにすることも検討できます。
S3とEFSは異なるデータストレージソリューションです。S3はオブジェクトストレージで、EFSはファイルストレージです。S3は、異なるユーティリティを介してマウントできるように見えますが、実際にはマウントできません。正しいS3 と EFS のどちらを使用するかは、そこにあるファイルをどのように使用するかによって異なります。
データベースについては、バースト可能なインスタンス クラスまたはサーバーレス オプションのいずれかを使用して、RDS への移行を検討することもできます。ただし、これは予算とユース ケースによって異なります。
答え2
一般的に、クラウドではサーバーではなくサービスを使用することをお勧めします。コストに注意する必要がありますが、ソリューションをより堅牢で高速かつ準拠したものにすることができます。
あなたの仕事量についていくつか考えがあります:
- AWS Step Functions のようなオーケストレーターを使用して、多数の AWS Lambda 関数を呼び出して計算を行うことはできますか? Lambda はおそらく AWS で最もコストのかかる計算時間なので、理想的ではないかもしれません。制限を適切に設定し、適切なワークロードを使用すれば、10,000 個の Lambda を開始して、15 分でジョブを並列実行できる可能性があります。
- EFS / S3 の代わりに、ゴールデン EC2 イメージ / AMI を作成し、ジョブごとに、その 1 つのジョブの処理を実行するのに十分な大きさのスポット / 動的 EC2 インスタンスを起動して、ジョブが完了したらシャットダウンするのはどうでしょうか。Lambda は、何らかのイベントに基づいてジョブをオーケストレーションできるでしょうか。そうすれば、データ転送料金を回避できますが、EBS / S3 に課金されるかどうかはわかりません。スポット コンピューティングは非常に安価であり、リージョン / AZ / インスタンス サイズを正しく選択すれば、中断はほとんど発生しません。中断されたインスタンスはシャットダウンされ、EBS ボリュームは保持されるため、ジョブが定期的にディスクに書き込まれ、再開できる場合は、この方法の方が適しています。
おそらく、その膨大な仕事を最適化するのにも時間をかけることになるでしょう。