AWS Transfer for SFTP サーバーでネットワークのレイテンシーを最低限に抑える

自社の SFTP サーバーにアクセスするクライアントが世界中にいる状態ですか? 世界中にいるエンドユーザーがサーバーのエンドポイントからの地理的距離のせいでパフォーマンス面での問題に直面していませんか? ユーザーのロケーションに関係なくすべてのクライアントに差のないパフォーマンスを提供できたら良いのにとお考えではありませんか? この記事では世界中で AWS Transfer for SFTP (SFTP) サーバーを設定することにより、そうしたユーザーに向けて低レイテンシーを実現できるベスト プラクティスを解説しています。また、Amazon Route 53 (Route 53) でレイテンシーに基づいたルーティングを使用し、レイテンシーの最も低い SFTP サーバーエンドポイントへユーザーを振り分ける方法についても指南します。

Route 53: レイテンシーベースのルーティング

以下のスクリーンショットのセットアップについて考慮します。詳細については後述します。

SFTP サーバーエンドポイントはロンドンリージョンでホストされており、ロンドンとシドニーからこのエンドポイントへアクセスするクライアントがあります。想定したとおり、ロンドンのクライアントではエンドポイントとバケットの両方がユーザーと同じ地理的リージョンにあるため、短いレスポンス時間で快適に操作できます。しかし、シドニーのクライアントでは高レイテンシーと接続性の悪さに苦労しています。

すべての地理的リージョンに広がるユーザーに一貫した使用性を提供するために、ユーザーのいる場所から近いところにある AWS リージョンに SFTP サーバーをセットアップしました。その後、Route 53 のレイテンシーベースルーティングを使用して、クライアントコンピューターからレイテンシーをベースに最も近いサーバーへトラフィックをルーティングします。私たちは専用のリージョン Amazon S3 バケットを SFTP サーバーにマッピングすることで、さらにこのセットアップを強化します。リージョンの Amazon S3 バケットのデータは、クロスリージョンレプリケーション経由で、マスターの Amazon S3 バケットへとレプリケーションされます。これは、すべての SFTP サーバーの共通データストアとして機能します。

世界中に分散されたアーキテクチャ:

上記シナリオでは、ユーザー P、R、および S はそれぞれ、ロンドン、シドニー、バージニア北部より接続しています。sftp.example.com へ接続しようとすると、そのリクエストは DNS 解決のため、Route 53 へと到達します。Route 53 はそれぞれのユーザーに対応するリージョンの SFTP サーバーの IP アドレスを提供します。これにより、ユーザーが体感する SFTP サーバーからのレイテンシーは最小限に抑えられることになります。

それでは、接続しようとしているユーザー Q のセットアップを見てみましょう。ユーザーのクライアントが接続を始めると、リクエストは 3 つのサーバー間でクライアントからのレイテンシーを判別および比較する Route 53 に到達します。ユーザー Q の最もレイテンシーの低い SFTP エンドポイントが判明すると、その SFTP サーバーエンドポイント (図上ではロンドン) の IP アドレスが返されます。この時点ではユーザーはそのエンドポイントを使用するよう接続されています。

自分のセットアップを構築する

セットアップを完了するには、S3 バケット、SFTP サーバー、SFTP ユーザー設定、Route 53 レコードを作成します。

S3 バケット:

自分のサーバーがある全リージョンで S3 バケットが必要になります。前からあるバケットを使用することも新しいバケットを作成することもできます。

SFTP サーバーを置いている全リージョンで S3 バケットが使用できるようになったら、マスターバケットとなるバケットをもう 1 つ作成します。これは自分で選んだリージョンに作成できます。つまり、サーバーのあるリージョンが 5 個あるとすると、S3 バケットが 6 個必要になります。

S3 クロスリージョンのレプリケーション:

S3 クロスリージョンレプリケーションをセットアップし、マスターバケットにすべてのリージョンバケットからのデータが集まるようにします。S3 クロスリージョンレプリケーションを全リージョンバケットに設定し、全リージョンバケットがマスターバケットへデータをレプリケーションするようにします。データ管理のためのポストアップロード処理を可能にするため、マスターの S3 バケットには S3 イベント通知を使用するようおすすめします。

SFTP サーバー:

SFTP を置こうとしているリージョンのすべてに、SFTP サーバーが必要になります。サーバーがすでに存在するときは、それらを使用することも新しいサーバーを作成することもできます。

DNS ホスト名を指定するときは、None または Other DNS を選択し、DNS ホスト名を指定します。Route 53 DNS Aliasオプションを指定すると、Route 53 セットアップで事前にレイテンシーベースのルーティングを設定できなくなります。

SFTP ユーザー設定:

ユーザー設定の実行中、以下のポインターには注意してください。

• 全サーバーで使用できるシングル資格情報ストアを設置することも、サーバーごとに複数の個別資格情報ストアを設置することもできます。管理のしやすさという点ではシングル資格情報ストアをおすすめします。さらに各リージョンの個別のレコードで、リージョンの S3 バケットへの認証を判別します。あるいは、ユーザーのログインレイテンシーを最小限に抑えるため、各リージョンで資格情報ストアの読み取りコピーを置くこともできます。
• 個々のバケットがマスターバケットへレプリケーションされるときは、別のユーザーによって書き込まれたオブジェクトが重ならないようにします。
• ユーザーの HomeDirectory を S3 のプレフィックスにマッピングするのに、他のユーザーのものと重ならないよう特別な命名メカニズムを使用するようおすすめします。これは論理ディレクトリとともに使用可能で、エンドユーザーは同じディレクトリ構造で表示されます。そうした理由から、これは、ユーザーが接続するエンドポイントとユーザーがアクセスする S3 バケットとは別ものとなります。

Route 53:

Route 53 のレイテンシーベースのルーティングをセットアップするために従う必要のあるステップを以下に示します。

1. Route 53 コンソールを開き、自分のホストゾーンまでナビゲートします。
2. [Create Record Set] を選択します。
   • Name: SFTP サーバーで使用する DNS ホスト名を入力します。
   • Type: CNAME を選択します。
   • Alias: No を指定します。
   • Value: 使用する SFTP サーバーのデフォルト DNS ホスト名をコピーします。この値は AWS Transfer for SFTP コンソールで、ご使用の SFTP サーバーの詳細情報にあるエンドポイントフィールドを確認してください。
   • Routing Policy: レイテンシーを選択します
   • Region: サーバーのあるリージョンを選択します。
   • Set ID: このフィールドはレイテンシーセットのグループのレコードセットを一意に識別します。このレコードセットを特定するのに役立つ任意の文字列を入力できます。例: Global SFTP <リージョン>
   • Associate with Health Check: No を指定します。
3. レコードセットを保存します。
4. 同様に、すべての SFTP サーバーにレコードセットを作成します。
5. 次の点を確認してください。
   • DNS ホスト名はステップ 2-A で指定した全レコードセットと同じである。
   • レイテンシーベースのルーティングに選択したリージョンが SFTP サーバーのリージョンと同じである。
   • ステップ 2-G の Set ID は全レコードセットで一意である。
6. 完了すると、ご使用のホスト名の CNAME DNS レコードがすべてのリージョン SFTP サーバーをポイントするようになります。

これでセットアップは終了です。DNS レコードが伝播されたら、自分の接続しようとしている SFTP サーバーを確認するため、ご使用のホスト名の DNS 解決をテストします。次のコマンドを使用できます。

• MAC または Linux: dig sftp.example.com
• Windows: nslookup sftp.example.com

セットアップをテストする

セットアップ:

以下はレイテンシーを比較するために私がセットアップをテストした方法です。

データ転送パフォーマンス:

データアップロードを測定し、すべてのテストで同じ 2GB のファイルを使用しました。ダウンロードパフォーマンスの測定にも同じテストを実行できます。

コマンド: sftp> put file.txt

結果の形式 – 転送速度 | 経過時間

シングルサーバーセットアップを使用し、「レイテンシーベースのルーティングなし」の条件では、Client 1 のパフォーマンスは Client 2 よりも良好な結果が出ました。クライアントがサーバーと S3 セットアップから地理的に離れていたため、およそ 5 分という大差がつきました。しかし、レイテンシーベースのルーティングを適用したあとでは、Client 1 と Client 2 とのパフォーマンスには差が見られなくなりました。これは、両クライアントともそれぞれのリージョンにあるサーバーと S3 セットアップに接続されたためです。

接続パフォーマンス:

netcat コマンドと time を使用して、接続タイミングの検証を行いました。

コマンド: time nc -vz sftp.example.com 22

「レイテンシーベースのルーティングなし」では、接続時間に約 200 ミリ秒の差が生じました。これが同一リージョン内の SFTP サーバーに接続されると差は 約 10 ミリ秒に縮まりました。

まとめ

このブログ記事では、レイテンシーを緩和するために、世界中に分散したエンドユーザーの各ロケーションに最も近い SFTP エンドポイントをセットアップし、ユーザーをルーティングする方法について手順を追って説明しました。AWS Transfer for SFTP を使用することで、世界規模で一貫したユーザーエクスペリエンスを提供できます。AWS Transfer for SFTP についてさらに詳しく学ぶには、SFTP 製品ページをご覧いただくか、AWS マネジメントコンソールでこのアーキテクチャの構築を始めてみましょう。記事を最後までお読みいただきありがとうございました。疑問やご意見がございましたら、以下のコメント欄でお知らせください。