著者: 禅とコンピュータープログラミングの芸術
1 はじめに
WebSocket (正式名: Web Sockets) は、単一の TCP 接続での双方向通信のためのプロトコルであり、サーバーがクライアントにデータをアクティブにプッシュできるようにします。クラウド コンピューティング、ビッグ データ、モノのインターネット、モバイル インターネット、その他のテクノロジーの台頭により、チャット ルーム、ビデオ会議、スマート ターミナル、ゲームのライブ ブロードキャスト、株取引シミュレーションなど、WebSocket をベースとしたアプリケーションがますます増えています。シナリオ。
従来の HTTP ベースのサーバー アーキテクチャでは、WebSocket をサポートするために負荷分散装置またはフレームワークを購入する必要がありますが、サーバーレス アーキテクチャではそのような複雑なアーキテクチャは必要ありません。この記事では、サーバーレス アーキテクチャを使用して、WebSocket 通信をサポートするメッセージ処理システムを構築する方法について詳しく説明します。
記事の主な内容は以下の通りです。
- サーバーレスとは何ですか?
- サーバーレス アーキテクチャを使用する理由
- サーバーレスアーキテクチャの長所と短所
- WebSocket とサーバーレスの実際の組み合わせ
- 付録 FAQ
- ソースコードリポジトリとサンプルコードのリンク
1.サーバーレスとは何ですか?
サーバーレス アーキテクチャは、サーバー インフラストラクチャを気にせずにアプリケーションを構築するプログラミング モデルです。開発者はビジネス ロジックに焦点を当て、API 呼び出し、イベント トリガー、またはツールやプラットフォームが提供するその他の形式の直接実行を通じてアプリケーション機能を実装するだけで済みます。サーバーレス アーキテクチャは、Amazon AWS Lambda、Microsoft Azure Functions、Google Cloud Functions など、広く使用されています。
サーバーレス アーキテクチャは、運用とメンテナンスのコストを削減できるだけでなく、ハードウェア投資、サーバー管理、構成の複雑さを排除するため、ユーザーがアプリケーションを迅速に起動できるようにすることもできます。サーバーレス アーキテクチャは開発コストと運用コストの削減に役立つため、企業は迅速なイテレーションを実現し、配信サイクルを短縮し、製品価値を高めることができます。
2. サーバーレス アーキテクチャを使用する理由は何ですか?
サーバーレス アーキテクチャではサーバーの管理が必要ないため、アプリケーションのデプロイとリソースの拡張が非常に簡単です。アプリケーションのトラフィックが一定のレベルに増加すると、より多くのリクエストを処理するためにサーバーの数を増やすことができ、トラフィックが減少すると、サーバーの数を減らしてリソースを節約することもできます。スタートアップ企業、個人プロジェクト、小規模チームの場合、アプリケーションを非常に簡単にデプロイできます。同時に、サーバーレス アーキテクチャはさまざまな変化にうまく適応し、サーバーや帯域幅などのユーザーの出費を節約できます。
サーバーレス アーキテクチャはシンプルで使いやすいですが、いくつかの制限もあります。まず、サーバーレス アーキテクチャはサーバー側の機能を完全に置き換えることはできません。たとえば、長時間の接続やサービス間呼び出しなどを処理する場合でも、タスクを処理するバックグラウンド サービスを作成する必要があります。次に、サーバーレス アーキテクチャでは、サードパーティ メーカーが提供するプラグインやサービスに依存する必要がありますが、これも面倒です。
実際のアプリケーションでは、マイクロサービス アーキテクチャ、コンテナ化アーキテクチャなど、ニーズに応じてさまざまなアーキテクチャ パターンを選択できます。
3. サーバーレスアーキテクチャの長所と短所
3.1 利点
- 従量課金制のサーバーレス アーキテクチャにより、企業は使用したリソースに対してのみ料金を支払うことができるため、コストが大幅に削減されます。さらに、ユーザーは、各サーバーの実行時間ではなく、機能の実行時間に対してのみ料金を支払う必要があります。
- 自動スケーリング サーバーレス アーキテクチャは、トラフィックのピーク時には自動的に拡張してユーザーのリクエストに対応し、トラフィックが少ない時には自動的に縮小します。これにより、リソースを効果的に節約し、効率を向上させることができます。
- サーバーレス環境のユーザーはソース コードをアップロードするだけで済み、サーバーレス アーキテクチャ プラットフォームは機能を実行するためにリソースを自動的に割り当てることができます。このアーキテクチャでは、サーバーやサーバー構成を管理する必要がなく、リソースの無駄がありません。
- 柔軟性と弾力性 プラットフォームはあまり多くのリソースを占有しないため、アプリケーションの使用状況に基づいてリソースの割り当てを動的に調整できます。これにより、弾力的なスケーラビリティも確保されます。
- 効率的な運用 サーバーレス アーキテクチャではサーバーを管理する必要がないため、高度な同時リクエストを短時間で完了でき、従来のアーキテクチャよりも効率的です。
- 運用コストの削減: サーバーを保守したり、ハードウェア デバイスの障害を心配したりする必要がないため、運用コストが削減されます。
- 従量課金制サービスの使用料金は、機能の実行時間に基づいて請求できるため、従来のアーキテクチャの固定料金モデルよりも柔軟です。
3.2 欠点
- レイテンシー 非同期アーキテクチャを使用しているため、関数呼び出しによって遅延が発生する可能性があります。ただし、これは並行処理によって軽減できます。
- 可用性 1 つの機能でエラーが発生すると、サービス全体の可用性に影響する可能性があります。
- 分離機能の実行環境は互いに独立しており、共有リソースにアクセスできないため、データ セキュリティの問題が発生する可能性があります。
- 実行速度 非同期アーキテクチャを使用しているため、関数の実行速度が制限される場合があります。関数の実行に時間がかかる場合、その実行結果が長時間待たされる可能性があります。
4. WebSocket とサーバーレスの実際の組み合わせ
前述のサーバーレス アーキテクチャをベースに、WebSocket テクノロジーと組み合わせることで、WebSocket 通信をサポートするメッセージ処理システムを構築できます。このシステムは、フロントエンド WebSocket リクエストを受信し、メッセージの内容を解析し、対応するバックエンド サービス インターフェイスを呼び出して処理することができます。
アーキテクチャ図は次のとおりです。
- フロントエンドは、WebSocket リクエストを WebSocket API に送信して、接続を確立します。
- WebSocket API はサーバーレス プラットフォームを呼び出し、フロントエンド WebSocket の仮想ネットワーク チャネルの確立を要求します。
- プラットフォームは、バックグラウンドで WebSocket 仮想ネットワーク チャネルを作成します。
- フロントエンドは WebSocket API にメッセージを送信し、API はそのメッセージをサーバーのメッセージ キューに渡します。
- サーバー側のメッセージ キューはメッセージを取得し、対応するバックグラウンド サービス インターフェイスを呼び出してメッセージを処理します。
- サーバーのバックグラウンド サービス インターフェイスはメッセージの処理を終了し、結果をメッセージ キューに返します。
- メッセージ キューは結果をフロントエンドに転送します。
- WebSocket API はメッセージをフロントエンドにプッシュします。
サーバーレス アーキテクチャを使用して WebSocket 通信を実装する利点は次のとおりです。
- ユーザーは事前にサーバーを購入する必要がなく、ビジネス ロジックの実装に集中するだけで済みます。
- プラットフォームは自動的に容量を拡張し、突然のトラフィックに迅速に対応できます。
- サーバー側のメッセージ処理コードは、ネットワークの輻輳などの問題を回避するために高度に最適化できます。
- ユーザーは、基盤となるネットワーク構造や帯域幅などの問題を心配する必要はありません。
5. よくある質問
5.1 クロスドメインの問題は発生しますか?
サーバーレス アーキテクチャ プラットフォームは通常、異なるドメイン名へのアクセスを提供するため、異なるドメイン名での WebSocket リクエストは異なるリクエストとみなされます。これは、リクエスト ヘッダーの Origin フィールドも変更されることを意味します。セキュリティ上の理由から、ブラウザはデフォルトでクロスドメイン要求をブロックするため、接続を正常に確立できません。ただし、クロスドメインの問題は、CORS (Cross Origin Resource Sharing) などのいくつかのクロスドメイン ソリューションを通じて処理できます。
5.2 役割の権限を機能ごとに個別に設定する必要がありますか?
サーバーレス アーキテクチャでは、各機能が独自の独立した実行環境を持ち、IAM (Identity and Access Management) ロールを使用してアクセス権限を制御できます。したがって、機能ごとに個別に権限を設定する必要はありません。
5.3 リクエストが失敗する理由は何ですか?
- WebSocket APIは作成されていません。WebSocket API を作成するには、AWS API Gateway を使用する必要があります。それ以外の場合は、追加のクラウド リソースを購入する必要があります。
- WebSocket API へのアクセスが許可されていません。API Gateway に関連する呼び出しメソッドを設定し、対応する権限を付与する必要があります。
- サーバー側のバックグラウンド サービスに問題があります。サーバコードが正しいか、サーバログの出力情報を確認してください。
- WebSocket API 呼び出しがタイムアウトしました。このような問題は、ネットワークの変動などによって発生する可能性がありますので、再度試してみるか、最新バージョンのソフトウェアにアップグレードしてください。
5.4 トラフィックとしてカウントされますか?
WebSocketを利用する際、ユーザーのリクエストはトラフィックとしてカウントされませんが、WebSocket接続の確立と切断はトラフィックとしてカウントされます。
5.5 WebSocket のステータスを監視するにはどうすればよいですか?
AWS CloudWatch を使用して、接続数、接続時間などを含む WebSocket のステータスを監視できます。