はじめに
前回に続き、今回はAWS PrivateLink経由でHULFT転送を行うにあたり相談や問合せが多い
- 設定できない
- 設定したものの転送できない
といった代表的な問題に対する具体的な確認方法を紹介します。
必ずしもHULFTによるファイル転送に限らない内容がほとんどですので
同様の状態で困っている方々の参考になればと思います。
なお、昨今ではPrivateLinkに関する記事も増えてきておりますので
基本的な設定要領や個別の説明はそちらへお譲りし、ここでは割愛します。
目次
つまづきポイント ~ HULFT のPrivateLink通信について問合せ、質問が多いものたち ~
問題1. 設定できない
問題2. 宛先ホスト名が長すぎて配信HULFTに設定できない
問題3. 接続エラーで通信できない
問題１ ： 設定できない
PrivateLink設定時に、宛先のエンドポイントサービスが見付からない場合等の相談が寄せられます。
このようなときに多いのは、
ケース1. 構築順序が合っていない
ケース2. 接続元AWSアカウントが接続先エンドポイントサービスに登録されていない
ケース3. 接続元／先で一致するAZが無い
ケース4. プロビジョニングされていない
という４つです。それぞれについて、簡単に説明します。
ケース１. 構築順序が合っていない
通信先となる方から順に①→②・・・→⑤と作成する必要があります。この順序どおりに設定を作成しない場合、例えば③LoadBalancerの②Listenerを作成しようとしても①TargetGroupが作成されていなければ指定できないため、構築できません。
削除する場合は原則として作成時の逆に接続元側から定義を破棄する必要があります。
ケース２. 接続元AWSアカウントが接続先エンドポイントサービスに登録されていない
図中の④へ接続する⑤を定義するには、⑤のAWSアカウントを④の許可プリンシパルに設定する必要があります。
設定する内容は接続元アカウントを許可するためのものなのですが、単純にAWSのアカウントIDを記載するのではなくIAMのARNというAWS独特の書式で記述する必要があります。
この設定先は、下図の「プリンシパルを許可」(英語画面の場合は「Allow principal」)タブにあります。
⑤「endpoint」作成時に④「endpoint service」が検索できない場合、先ずこの指定内容を確認しましょう。
ケース３. 接続元／先で一致するAZが無い
PrivateLinkの接続元（図中の⑤）と接続先（図中の⑥）のAZ（アベイラビリティゾーン）について、異なるVPC同士なのでサブネットが展開されているAZが異なっている場合があります。
例えば、接続元がxxx-1aとxxx-1cであり、接続先がxxx-1cとxxx-1dで構成されている場合はxxx-1c部分が一致するため、冗長性は確保出来ないものの接続は可能です。
ところが、接続元／先で一致するAZが存在しない場合、接続元側のエンドポイント（図中の⑤）作成時に接続先となるエンドポイントサービス（図中の⑥）が見付かりません。
こうした場合、VPCのAZを追加するなどして一致するAZを確保する必要があります。
AZはAWS側のリソース増強により新たに追加される場合があります。例えば接続先となるエンドポイントサービス生成時には存在しなかったAZが、接続元となるエンドポイント作成時に存在して割り当てられる可能性があります。
ケース４. プロビジョニングされていない
AWSの各種リソースには生成に時間を要するものがあります。
例えば、図中③のようにプロビジョニングが必要なリソースは、定義を作成してから動作できるようになるまでに時間がかかります。
こうした場合、例えば下図のように対象リソースのステータスがプロビジョニング中（provisioning）という状態に見えます。
この準備が整う（「Active」という状態に見える）までは、利用する事ができません。
問題２ ： 宛先ホスト名が長すぎて配信HULFTに設定できない
PrivateLink経由でHULFT転送を行う場合、配信側HULFTの宛先は自VPCに設けられたEndpointとなります。
これを宛先とする場合のホスト名はEndpointのDNS名となり、一般的に100文字前後となります。
つまりHULFTに登録できる宛先ホストの最大ホスト名長である68文字を大幅に超えてしまいます。
これに対処する方法は、以下の２点が考えられます。
- ROUTE53にDNSのAレコードとして短い名前のホスト名を追加する
- hostsファイルのIPアドレスに短いalias名を設定する
上記2による対応の方が手軽なのですが、宛先EndpointServiceがAZ分散を行っている場合には利用できません。
問題３ ： 接続エラーで通信できない
ケース１. 疎通確認方法がわからない
PrivateLinkはTCP通信しか通さないため、TCPでなくICMPプロトコルを利用するpingコマンドは利用できません。
このため配信側ホストから相手先集信へ通信可能かどうかを確認するには「utlalivecheck」というHULFTのユーティリティ（利用方法は本リンクを参照ください）を利用します。このコマンドは、元来は集信プロセスの起動状態を確認するためのものですが、HULFTの転送と同様に実際に集信プロセスへのTCP接続を試みるため、疎通確認にも利用することができます。
ケース２. どこまで通信が到達しているか分からない
転送の通信は下図の構成で、ClientApplicationと記載されているHULFTインストール環境→⑤→④→③と流れます。
それぞれまで通信が到達しているか否かの確認方法を紹介します。
以降の画面例で示すAWSのモニタ画面は、表示される内容にタイムラグがあります。
通信内容が見えるまでに数分かかりますので、４～５分程度は監視を続けてみてください。
ケース２.1 ⑤の Endpoint のモニタ画面
AWSコンソールのVPC＞Endpointsメニューより対象を選択し「Monitoring」タブを選択します。
通信が届くと「New Commections」等のグラフに変化が現れます。
ケース２.2 ④の EndpointService のモニタ画面
AWSコンソールのVPC＞Endpoint servicesメニューより対象を選択し「Monitoring」タブを選択します。
通信が届くと「New Commections」等のグラフに変化が現れます。
ケース２.3 ③の LoadBalancer のモニタ画面
AWSコンソールのEC2＞Load Balancingメニューより対象を選択し「Monitoring」タブを選択します。
通信が届くと「New flow count」や「New flow count TCP」等のグラフに変化が現れます。
ここまで問題無く通信が通っていれば、残る問題要因は以下です。
１ TargetGroupの宛先アドレスやポートが間違っている
２ 受信（集信）サーバ環境のセキュリティグループが通信を許可していない
３ 受信（集信）サーバ環境のファイアーウォール（IPTables等）が通信を許可していない
おわりに
今回はPrivateLinkを構築してHULFT転送を試みる際に、主に発生する問題の確認方法について記載しました。
次回は、これら疎通確認が済んだ後で、さらに寄せられる一見不可解に見える現象に対する質問や確認事項について記載したいと思います。