この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
コンビニで売っているカット済みの梨から秋を感じる程度に、インドアな日々を過ごしています。
▲ ちょっと割高だけど、カット済みだし甘くて美味しいです
この間は、秋晴れがあまりに清々しくて青空を見ながら二度寝をしてしまいました。AWS事業本部のShirotaです。これこそが休日の正しい過ごし方ですよね。
さて、今日は特に上手い繋ぎが浮かばなかったのでこのまま本題に入ります。
美味い繋ぎは梨って事です
Amazon MQの可用性を考える
どんなサービスでも、障害時の事を考えて可用性を高めておく事は大事です。 例えばAmazon MQと言う、Apache ActiveMQをマネージドしたメッセージブローカーサービスがあります。 公式のページへのリンクを以下に記載しておきます。
Amazon MQはメッセージブローカーを作成し、そこにアプリケーションを接続することによってメッセージの送受信をする事ができます。 このメッセージブローカーは2つの異なるアベイラビリティーゾーンにブローカーをそれぞれ配置するといった高可用性対応アクティブ/スタンバイブローカーというものが作成でき、可用性を高めるアーキテクチャが用意できるようになっています。 また、ブローカー同士を接続する事によってブローカーのネットワークを確立する事ができます。 ブローカーのネットワークを確立する事によって可用性やスケーラビリティを確保する事ができるようになる為、アプリケーションから求められる事に併せて考慮する事が大事となります。 様々なネットワークについては、以下の公式ガイドに記載があるので参考にどうぞ。
今回は、可用性を考慮して クロスリージョン でブローカーのネットワークを設定してみたので、手順をまとめてみました。
ブローカーネットワークをクロスリージョンで設定してみた
今回設定するアーキテクチャは以下のようになります。
▲ 単一インスタンスブローカーを接続します
東京リージョンに作ったブローカーとシンガポールリージョンに作ったブローカーを接続してみます。
ブローカーのネットワークを接続する為の前提条件
早速ブローカーのネットワークを設定していきたいのですが、その際に前提として以下が成立していないといけません。
ブローカーは同じVPCまたはピア接続されたVPCに属している必要がある
今回はクロスリージョンでの接続となるので、VPC Peering を設定しておく必要があります。
同時にアクティブな2つ以上のブローカーが必要
今回は単一インスタンスブローカー同士の接続なので特に問題無いのですが、高可用性対応アクティブ/スタンバイブローカーを接続する時は、アクティブブローカーを必ず接続しましょう。片方のAZのアクティブブローカーともう片方のAZのスタンバイブローカーだけを接続するといった事をすると条件が満たせません。
接続するブローカー同士、同一名のユーザーが必要
後述しますが、ブローカー間の認証情報を引き渡す場合、ブローカーのConfigurationにnetworkConnectorsを記述する事でクレデンシャルを渡せます。 Configurationは起動時に読み込まれ、networkConnectorsのuserNameからAmazon MQは自動でパスワードを引っ張ってきます。 この際、両方のブローカーに 同じ名前・パスワードのユーザー が存在している必要があります。
ブローカーを用意する
ブローカーの接続を試す前に、各リージョンに用意したパブリックサブネットに単一インスタンスブローカーを用意しました。 一旦、各ブローカーにWebコンソール上でアクセスできるか確認します。
▲ Webでアクセスする際には8162ポートを開ける必要がある
▲ これが東京側のブローカー
▲ これはシンガポール側のブローカー。URLくらいしか違う箇所がないので分かりづらい
では、下準備が整ったので設定していきましょう。
ブローカーを接続する
シンガポール側のブローカーの設定
今回は、東京からシンガポールにduplex(双方向)の接続を作成します。 duplexの接続を作成すると、ブローカーの間でメッセージ転送が提供されます。 つまり、片方のブローカーのメッセージは、もう片方のブローカーに転送されます。 逆に、東京からシンガポールに一方通行の接続を作成した場合、東京のブローカーのメッセージがシンガポールのブローカーに転送されますが、シンガポールのブローカーのメッセージは東京のブローカーには転送されません。
まず、ブローカー間でのOpenWireエンドポイントでの通信を許可します。 今回は、シンガポールのブローカーがあるセキュリティグループに東京のブローカーからの通信を許可する設定を追加します。
ブローカーに与えられているIPアドレスは以下から確認できます。
▲ これはブローカーを再起動しても変わる事がないIPアドレス
▲ OpenWireエンドポイントのポートを開ける
東京側のブローカーの設定
次に、東京のブローカーの設定をします。 前述しましたConfigurationを設定して、東京のブローカーがシンガポールのブローカーに接続するようにネットワークコネクターについて記述します。
Configurationは左カラムから移動できます。
▲ 利用しているConfiguration名を確認しておく
Configurationは、デフォルトではネットワークコネクターの項目がコメントアウトされています。
<!--
<networkConnectors>
<networkConnector name="myNetworkConnector" userName="commonUser" uri="masterslave:(ssl://b-1a2b3c4d-1.mq.region.amazonaws.com:61617,ssl://b-1a2b3c4d-2.mq.region.amazonaws.com:61617)"/>
</networkConnectors>
-->
</broker>コメントアウトを参考にして、broker内に記述していきます。 今回は、事前に双方に作成済みの「testuser」で、duplex接続あり、単一インスタンスブローカー同士の接続(static)を設定してみます。 因みに、高可用性対応アクティブ/スタンバイブローカーと接続する時にアクティブ/スタンバイ双方のブローカーのuriを記述する場合は上記のコメントアウトされた例文のように「masterslave」と設定します。
<networkConnectors>
<networkConnector name="connector_tokyo_to_singapore" userName="testuser" duplex="true"
uri="static:(ssl://X-XXXXX-XXXXXXXX-XXXXX-X.mq.ap-southeast-1.amazonaws.com:61617)"/>
</networkConnectors>上記を記載する為、Configurationを編集します。
▲ Edit configurationを選択
今回、「connector_tokyo_to_singapore」という名前で接続を作成しました。 Configurationを保存しようとすると、以下のポップアップが出ます。 今回は、このリビジョンの説明を記載してから保存しました。
▲ オプションなので必須ではないが、記載した方が分かりやすい
これでConfigurationの設定は完了……と言いたいのですが、このままですと変更は 次回のメンテナンスウィンドウ の時間帯に適用されます。 今回は、すぐに適用して検証したいのでConfigurationを適用するように変更します。
▲ この通り、まだリビジョンがデフォルトのままなので編集する
▲ 先程作成したリビジョンを選択
変更をかけようとすると、変更を適用するタイミングを選択する事になる為、ここで「即時適用」を選択します。
▲ 再起動でダウンタイムが発生するので注意
再起動には、 約5分前後 かかります。
再起動後、ネットワークコネクターが作成されている事がコンソール上で確認できます。
▲ 作成したネットワークコネクターが表示されている！
さて、実際にWebコンソール上で設定が適用されているかを確認しましょう。
東京のブローカーのコンソールでは、ネットワークブリッジの項目が以下のようになっていました。
▲ シンガポール側のセキュリティグループの設定が適用されている
シンガポールのブローカーのコンソールでは、ネットワークブリッジの項目が以下のようになっていました。
▲ 折り返しのポートは指定のものとは違った
今回、片方のduplexのステータスがfalseになっていますが、この状態でも相互にメッセージの転送はできます。 これに関しては、公式ガイドに以下のような記述がありますので引用しました。
ブローカーのネットワーク内の接続を使用し、またメッセージを生成するかどうかを指定します。ブたとえば、ブローカー A が非二重モードでブローカー B への接続を作成した場合、メッセージはブローカー A からブローカー B にのみ転送できます。ただし、ブローカー A がブローカー B への二重接続を作成した場合、ブローカー B は を設定しなくてもメッセージをブローカー A に転送できます。
接続の確認
試しに、シンガポールのブローカーでPub/Subを実施してみます。 今回は、以下ブログを参考にしてMQTTを使用して検証しました。
【速報】新サービスAmazon MQを早速使ってみた！ #reinvent
シンガポール側のブローカーのコンソールを確認します。
▲ MQ Test Singapore-to-Tokyoというトピックを発行してみました
この時、東京側のブローカーを確認してみますと、トピックが転送されている事が確認できました！
▲ 接続前のテストのトピックは転送されていない事は画像から確認できます
双方向の転送ができるようになっているかを確認したいので、東京のブローカーでもPub/Subを実施してみます。 東京側のブローカーのコンソールを確認します。
▲ 今度はMQ Test Tokyo-to-Singaporeというトピックを発行します
この時、シンガポール側のブローカーを確認すると、トピックが転送されている事が確認できました！
▲ 双方向で転送できました
やりたい事に応じてブローカーネットワークを活用しよう
実際に、クロスアカウントでブローカーネットワークを設定してみたのですが、duplexが使える事によりConfigurationの設定も少なく、楽に設定する事ができました。 前述致しましたように、公式ガイドには可用性・スケーラビリティを意識した様々なネットワークが記載されています。 その中の一つの可用性のあるアーキテクチャとして、今回のAmazon MQをクロスアカウントで接続するネットワークを考えて頂けると良いのではないかと思います。
このブログが、クロスアカウント接続を設定してみたい方の助けになれば幸いです。
3
