WebSocket

WebSocketについて：

①AWS のサービスの (Lambda や DynamoDB など) または HTTP エンドポイントのステートフルな

フロントエンドとして、WebSocket API を作成できます。

②WebSocket API は、クライアントアプリから受信するメッセージのコンテンツに基づいて

バックエンドを呼び出します。

Restfulとは

REST：

①HTTPメソッドを使い、必要な情報のやり取りするための仕組みを提供する。

②利用者が自分でWEbブラウザからアクセスして使用するのではなく、”他のプログラムがアクセスして利用”

するための物

ApiGatewayについて

参照先：

https://dev.classmethod.jp/cloud/aws/getting-start-api-gateway/

リソース：Apiのパスを表す。

①デフォルトが “ /  “のみなので、http://api-endpoint.comにした場合は、アクセス先になる。

②http://api-endpoint.com/testと追加を行うと、パスを深くすることも可能。

リソース内に、メソッドを定義している。

メソッド：

httpプロトコルを使用して、サーバに対して要求することを指す。

testに対して、POSTメソッドを定義すると、http://api-endpoint.com/testに対して

POSTリクエストがあった時に定義される

HTTPメソッド

メソッド	意味
GET	リソースの取得
POST	子リソースの作成、リソースへのデータ追加、その他処理
PUT	リソースの更新、リソースの作成
DELETE	リソースの削除
HEAD	リソースのヘッダ (メタデータの取得)
OPTIONS	リソースがサポートしているメソッドの取得
TRACE	プロキシ動作の確認
CONNECT	プロキシ動作のトンネル接続への変更

CRUD：

CRUDはCreate, Read, Update, Deleteのこと。

HTTPメソッドのうちGET、POST、PUT、DELETEは「CRUD」を満たす

CURD名	意味	メソッド
Create	作成	POST/PUT
Read	読み込み	GET
Update	更新	PUT
Delete	削除	DELETE

Content-Type： 

使いそうなのだけ抜粋

Content-Type	Kind
text/plain	テキストファイル
application/xml	HTMLファイル
application/json	JSONファイル

以下はメソッドの一覧である。

○は仕様として定義されているもの、△はAppendixとして示されており、正式な仕様ではないものである。

メソッド	HTTPバージョン		意味
	1.0	1.1
GET	○	○	URIで指定した情報を要求。URIがファイル名のときはそのファイルの中身を、プログラム名のときはそのプログラムの出力を返す
HEAD	○	○	GETと同じだがHTTPヘッダのみを返す
POST	○	○	クライアントからデータを（名前と値）のセットで渡す。フォームデータを送るときなどに使用
OPTIONS		○	通信オプションの通知など
PUT	△	○	URIで指定したサーバ上のファイルを置き換える
DELETE	△	○	URIで指定したサーバ上のファイルを削除する
TRACE		○	サーバが受け取った要求行とヘッダ行をそのまま送り返す
PATCH		△	PUTと同じだが、差分のみを置き換える
LINK		△	他の情報との関連付け
UNLINK		△	LINKで設定した関連を外す

ELBに関するHTTPコードについて

HTTPCode_Backend_2XX：

(3)及び(4)のレスポンスで200系のHTTPレスポンスを行い、(1)〜(4)までのステップを全て正常に完了した場合、HTTPCode_Backend_2XXとしてカウントされます。

一般的に最も健全な動作と言えるでしょう。

HTTPCode_Backend_4XX：

(1)〜(4)までのステップを全て正常に完了したのだが、3のレスポンスが400系レスポンスであり、その結果(4)のレスポンスが400系として完了した場合、これはHTTPCode_Backend_4XXとしてカウントされます。存在しないリソースにアクセスして404がとなった場合や、Web APIに於いて必須のパラメータが足りなかった場合の400レスポンス等、クライアント側の「リクエストの仕方」に問題がある場合、400系のレスポンスを返すのが一般的ですね。

HTTPCode_Backend_5XX：

(1)〜(4)までのステップを全て正常に完了したのだが、(3)のレスポンスが500系レスポンスであり、その結果(4)のレスポンスが500系として完了した場合、これはHTTPCode_Backend_5XXとしてカウントされます。アプリケーション層でのエラーにより正常なレスポンスが返せなかった場合の500、メンテナンス中の503等、

エラーの原因がサーバ側にある場合、500系のレスポンスを返すのが一般的です。

ELBが独自の判断によりステータスコードを返す場合（HTTPCode_ELB_*）

以上の通り、普通は「バックエンドから受け取ったレスポンス(3)をそのままクライアントに返す(4)」のが

ELBの動きです。

しかし、特定の状況下ではELBは独自の判断で(4)のレスポンスを行います。

HTTPCode_ELB_4XX：

①HTTP 400: BAD_REQUEST

そもそも(1)のリクエストが日本語でおｋHTTPリクエストとして解釈不能な場合、ELBは(2)のリクエスト転送を行わず（行えず？）、400を返します。

②HTTP 405: METHOD_NOT_ALLOWED

(1)のリクエストにおけるHTTPメソッド名（GETやPOST等）が127文字を超えていた場合、ELBは(2)のリクエスト転送を行わず、405を返します。

HTTPメソッドは、よく知られたGET, POST, OPTIONS等の他に、独自の拡張が可能です。（RFC 2616 Section 5.1.1参照）

このような拡張を利用していた時、無駄に長いHTTPメソッド名が使われる可能性もゼロではありません。

HTTPの仕様上、この長さには制限は無いようですが、ELBとしては127文字を上限としているようです。

③HTTP 408: Request Timeout

(1)のリクエストでタイムアウトが発生した場合、ELBは(2)のリクエスト転送を行わず（行えず？）、408を返します。

例えば、ネットワーク切断が発生した場合や、Content-Lengthの値よりも実際のサイズが小さくてELBが続きを待ってしまう場合など、ELBが(1)の完了を認識できずにタイムアウトした場合があてはまります。

HTTPCode_ELB_5XX：

①HTTP 502: Bad Gateway

(3)のレスポンスが日本語でHTTPレスポンスとして解釈不能な場合、ELBは502を返します。

②HTTP 503: Service Unavailable(ELBの高負荷系)

Case 1:

突発的なアクセスによりELB自体がキャパシティを超えてしまった場合です。

ELBは、負荷に応じて自動スケールします。

 ->ELBを突発的な負荷が襲った場合、スケーリングが間に合わないことがあります。

また、負荷により「スケールアップ」が行われた場合、ELBのDNS名から正引きされるIPアドレスが変わります。

つまり、古い（小さな）インスタンスと、新しい（大きな）インスタンスにバトンタッチが起こります。

しかし、クライアントがDNSキャッシュを持っていた場合、スケールアップ前の古いインスタンスに対してリクエストを送り続けてしまうことがあります。

こういった場合にも、キャパ超えのレスポンスとして503が返されるでしょう。

このようなケースに対しては、ベンチマークツール等を利用して本番想定の負荷をあらかじめ掛けておき

ELBの自動的なスケーリングによる調整を期待した上で、本番運用を開始するといった対応が必要です。

このような対応が行えない場合、AWSサポートのビジネスまたはエンタープライズに加入しているのであれば

暖気申請を行うことも可能です。

AWSサポートに対して、いつ頃どの程度のリクエストが来るのか、事前に通知を行うことにより、リクエストを充分受け付けられる規模にあらかじめスケールをしてもらえます。

Case 2: 

(3)を行った後(4)が返ってくるのに時間が掛かり、(3)のリクエストがタイムアウトした場合です。

このタイムアウト時間は通常60秒です。

このケースに対応する場合、アプリケーションが60秒以内にレスポンスを返すように何らかの対応を行うのが

第一選択ですが、サポートに依頼することによりタイムアウト時間を最大17分まで延長することができるようです。