自動化されたソフトウェア システムを構築するということは、専用の CPU 構成、メモリ、ストレージ、およびその他のリソースを備えた複数のサーバーを長年セットアップすることを意味していました。 次に、これらのシステムを管理するための管理者チームが編成されました。 その後、開発チームがインフラストラクチャを引き継ぎ、サーバーを接続するプロセスの作成を開始しました。
このプロセスは、多くの異なるグループが共通の目標に向かって協力する必要があるため、複雑になる可能性があります。 これらの利益相反が問題になる可能性があります。
また、かなりの費用がかかる場合があります。 これには、給与計算に管理者が必要です。 継続的に実行されるサーバーは、使用されていなくてもリソースを消費します。
長期にわたって最高のパフォーマンスを維持するには、サーバー リソースを自動的にスケーリングする自動スケーリング ソリューションが必要です。
クラウド プラットフォームには 1 つの利点があります。それは、サーバー クラスターのセットアップを必要とせずに、エンド ツー エンドのアーキテクチャを作成できることです。 管理の観点からは、維持するものは何もありません。
これは、スタートアップやプロジェクトの実用最小限の製品 (MVP) フェーズにとって費用対効果の高いオプションです。 将来の本番環境の負荷とユーザー アクティビティを予測するのが難しい場合は、これが出発点として適しています。 これは、クラスタ サーバーの構成を決定するのが難しい場合があります。
サーバーレス クラウド サービスによるプロセスの自動化は、サーバーレス アーキテクチャを際立たせるものです。 サービスを接続し、従来のクラスター サーバーと同様の結果を生成します。
これは、ネイティブの AWS サービスのみを使用してそのようなアーキテクチャを構築する例です。
サービスのサーバーレス フローを取り上げる
いくつかの具体的な資産のインフラストラクチャ (製造またはユーティリティ資産である可能性があります) のさまざまなデータと写真 (または写真) を収集するためのプラットフォームを作成したいとします。
- 将来の分析を可能にするためには、受信データを最初に取り込む必要があります。
- ビジネス ルールを適用した後、バックエンド プロシージャは、計算された出力を正規化された情報としてリレーショナル データベースに保存します。
- 正規化されたクリーン データを表示するアプリケーション フロントエンドにより、ユーザーは結果を表示できます。
アーキテクチャに含めることができるコンポーネントを調べてみましょう。
AWS S3 バケット
ソース: aws.amazon.com
Amazon S3 バケットは、ファイルや写真を AWS クラウドに保存する優れた方法です。 S3 バケットのストレージの価格は非常に低くなっています。 さらに、S3 バケットのライフサイクル ポリシーを導入すると、この価格がさらに下がります。
このようなポリシーは、アーカイブやディープ アーカイブ アクセスなど、古いファイルを S3 バケットのさまざまなクラスに自動的に移動します。 クラスはアクセス時間の速度によっても異なりますが、古いデータの場合、これは問題になりません。 これは主に、標準的な操作のニーズではなく、緊急のイベントの場合にアーカイブされたデータにアクセスするために使用されます。
- サブフォルダーでデータを整理できます。
- 適切な権限制限を設定する必要があります。
- バケットにタグを追加して、識別しやすくし、動的な S3 バケット ポリシー内で使用できるようにします。
- バケットは設計上サーバーレスです。 これは単なるデータのストレージ スペースです。
S3 バケットは、設計上サーバーレスです。 これは単なるデータのストレージ スペースです。
AWS アテナ データベース
ソース: aws.amazon.com
Athena を使用すると、AWS の基本的なデータ レイクを簡単に作成できます。 これは、S3 バケットを使用してデータを保存するサーバーのないデータベースです。 データ編成は、寄木細工やコンマ区切り値 (CSV) ファイルなどの構造化ファイル形式によって維持されます。 S3 バケットはファイルを保持し、プロセスがデータベースからデータを選択するたびに Athena がファイルを参照します。
Athena は、update ステートメントなど、それ以外の場合は標準と見なされるさまざまな機能をサポートしていないことに注意してください。 これが、Athena を非常に単純なオプションと見なす必要がある理由です。
ただし、インデックス作成とパーティショニングはサポートしています。 また、インフラストラクチャに新しいバケットを追加するのと同じくらい複雑であるため、非常に簡単に水平方向にスケーリングできます。 シンプルでありながら機能的なデータ レイクを作成するには、ほとんどの場合、これで十分です。
優れたパフォーマンスを得るには、将来の使用に重点を置いて最適なデータ設計を選択することが不可欠です。 データを選択する方法を明確にすることが不可欠です。 テーブルがすでに存在し、大量のデータで満たされている場合、後でテーブルを再作成することは困難です。
Athena DB は優れた選択肢であり、時間の経過とともに水平方向に簡単にスケーリングできるシンプルで不変のデータ プールを作成しようとしている場合に最適です。
AWS オーロラ データベース
ソース: aws.amazon.com
Athena DB は、キュレーションされていないデータの保存に優れています。 結局のところ、これは元のコンテンツを保存して将来の再利用を最大化する方法です. ただし、選択した結果をフロントエンド アプリに提供するには時間がかかります。
主に実行しやすいセットアップの観点から、最良のオプションの 1 つは、サーバーレス モードで実行される Aurora データベースです。
Aurora は、基本的なデータベースにはほど遠いものです。 これは、AWS で最も高度なネイティブ リレーショナル データベース ソリューションの 1 つです。 また、リリースごとに改善される非常に複雑なネイティブ リレーショナル データベース ソリューションでもあります。
Aurora はサーバーレス モードで実行できるため、他のリレーショナル サービスとは一線を画しています。 モードの仕組みは次のとおりです。
- Aurora クラスターを構成するには、AWS コンソールを使用します。 標準の CPU と RAM のレベル、および自動スケール機能の最大間隔を指定する必要があります。 これは、Aurora クラスターが動的に追加または削除できるパフォーマンスに影響します。 データベースの現在の使用率に基づいて、AWS はスケールアップまたはスケールダウンを決定します。
- ユーザーまたはプロセスが実際のリクエストを開始しない限り、Aurora クラスターは起動しません。 たとえば、スケジュールされたバッチ処理が開始されたときです。 または、アプリケーションがバックエンド API 呼び出しを実行してデータベースからデータを取得する場合。 データベースは自動的に開き、要求プロセスが完了した後、所定の時間アクティブなままになります。
- データベースに作業がなくなると、Aurora クラスターは自動的にシャットダウンします。
もう一度強調すると、サーバーレス Aurora DB は、実際の作業を行う必要がある場合にのみ実行されます。 自動的に起動されたクラスターは、作業を処理していない場合、再びシャットダウンします。 実際の作業は、アイドル時間ではなく、支払うものです。
サーバーレス Aurora は AWS によって完全に管理されており、管理者は必要ありません。
AWS増幅
Amplify は、JavaScript および React ライブラリで作成されたフロントエンド アプリケーションを迅速にデプロイするためのサーバーレス プラットフォームを提供します。 クラスタ サーバーをセットアップする必要はありません。 AWS コンソールを使用してコードを直接デプロイするか、自動化された DevOps パイプラインを使用します。
バックエンド API を呼び出して、データベースに保存されているデータにアクセスできます。 これらの呼び出しにより、フロントエンド アプリケーション内の実際のデータにアクセスできます。 バックエンドのパフォーマンスの主な最適化は、チームが行う必要があります。 API 呼び出し内で効果的な選択ステートメントを直接設計すると、UI での応答が遅くなる可能性をさらに減らすことができます。
AWS ステップ関数
ソース: aws.amazon.com
システムの主要コンポーネントはすべてサーバーレスですが、これは完全なサーバーレス アーキテクチャを保証するものではありません。 これは、コンポーネント間のすべてのバッチ プロセスがサーバーレスである場合にのみ可能です。
AWS Step 関数は、AWS クラウドで最高のソリューションを提供します。 AWS Lambda 関数の接続されたリストがステップ関数を構成します。 これらの関数は、開始と終了の状態が明確なフローチャートを作成します。 通常、Python または Node JS 言語で記述されるラムダ関数は、必要なものを処理する実行可能なコードです。
以下は、ステップ関数を実行する方法の例です。
このサーバーレス フローには大きな欠点が 1 つあります。それは、各ラムダ関数を最大 15 分間しか実行できないことです。 したがって、フローをより小さなラムダ関数に分割すると、問題が軽減されます。
1 つのステップで複数のラムダ関数を同時に呼び出すことができます。これは基本的に、複数のラムダを同時に実行するステップを並列化することを意味します。 続行する前に、すべての並列ラムダ処理が終了するのを待ってください。 その後、次のラムダ処理に進みます。
最後の言葉
サーバーレス アーキテクチャは、システム ランドスケープ全体をカバーするクラウド プラットフォームを作成するユニークな機会を提供します。 このプラットフォームは水平方向にスケーラブルであり、その間の運用コストは低くなります。
予算に制約のあるプロジェクトに最適なソリューションです。 これは、通常、実稼働負荷の実態を誰も知らない場合に最適な調査オプションです。 これは、すべてのユーザーのオンボーディングに成功した後で特に重要です。 プロジェクト チームは、システムがどのように機能するかの全体像を把握することができます。 これらすべての利点を得ることができ、妥協を受け入れる必要はありません。
このカバレッジは、特に CPU 使用率が高い場合など、すべてのケースに適しているわけではありません。 ただし、AWS クラウドはサーバーレスのユースケースに関して常に進化しています。 通常、次の AWS クラウド プロジェクトのサーバーレス オプションを決定する前に、徹底的な調査を行うことをお勧めします。
次に、最新のアプリケーションに最適なサーバーレス データベースを確認してください。
