【続】AWSでBizRobo!Basicが動く環境を構築してみた

こんにちは。
自称）BizRobo!エンジニアのもりりんです。

今回は、「【続】AWSでBizRobo!Basicが動く環境を構築してみた」です。

AWSでBizRobo!Basicが動く環境を構築してみたでAWS上にBizRobo!環境を構築した際のブログを書きましたが、実際に検証していくと記載した方法では正常に動作しない等々、多々アクシデントに見舞われました。
そのときの問題と解決方法について、備忘録としてまとめます。
備忘録として記載のため、普段のブログとは書き方が異なることご了承ください。

以前の問題点

それぞれの問題について

 AWSのネットワークACL/セキュリティグループの接続ポートを最低限に抑えると、MC/RDPもアクセスできなくなった

こちらは題名の通り、セキュリティ対策で開放するポートを必要な分だけ設定すると、アクセスができなくなる問題でした。
イントラ内に存在するMC/DAサーバでネットワーク上に開放が必要なポートは、以下です。

しかし、AWSはインターネット上にあるサービスです。
そう簡単には対応させてもらせないのは分かっていましたが、ネットワークエンジニアでは無い私にはここで大きな壁が…
ということで、対応してみるとまさかの2日もかかってしましましたが、AWSの勉強になったので良しとしましょう。

ネットワークの説明に入る前に、そもそも各OS毎にTCP/IPレイヤーでの通信時に利用されるポート（Ephemeralポート）が設定されていることを知っておきましょう。
これらのポートを適切に開放していない場合、そもそも通信に失敗します。

そもそもポートには、下記の画像のように3つの区切りが存在します。

RFC 6056では、Ephemeralポートには目次のユーザーサポートと動的・私用ポートを合わせた「1024 ~ 65535」を指定するようにを提言されていますが、実際はOS毎に異なるため調べておきましょう。
Windows VistaまたはWindows Server 2008以降は、「49152 ~ 65535」を利用しています。
参照：エフェメラルポート

話は戻って、AWSのセキュリティ設定であるネットワークACLとセキュリティグループですが、役割が異なるためそれぞれ適切に割り当てましょう。
2つの違いは、以下のようになっています。

前回のイメージに補足を入れるとイメージしやすいかと思います。

最初に手を入れやすい設定は、EC2やロードバランサに設定するセキュリティグループです。
サーバに対してアクセス制限を追加するだけなので、外からアクセスされてもいいポート（インバウンドルール）のみ開放します。
ただし、不正アクセスを防ぐため接続元IPは必ず指定しましょう。

なお、8080のTomcatポートはMCサーバ内のlocalhostもしくはロードバランサからしか利用しないため、VPCにデフォルトで付属しているセキュリティグループでカバーします。
デフォルトのセキュリティグループを利用すると、同一VPC内であればサブネットが異なっていても全ポートの通信が許可されます。
なので、VPCよりも外からのアクセスは作成したセキュリティグループ、VPC内のアクセスはデフォルトのセキュリティグループに任せる構成にします。

MC用の設定が終わったら、DA用のセキュリティグループも同様に必要なインバウンドルールを設定しましょう。

ロードバランサ向けのセキュリティグループについては特に指摘することもありませんが、、HTTP(S)通信に必要な80/443ポートのみ開放します。
ちなみに、HTTP(80)アクセスはロードバランサ側でHTTPS(443)にリダイレクトするように設定しておきましょう。
HTTPS(443)だけ使うからと、HTTP(80)ポートの開放しない場合、ロードバランサからMCサーバへ通信を転送できずタイムアウトでエラーになるため注意しましょう。

 問題は、ネットワークACLです。

できれば全開放しておきたいところですが、ロボット開発時にロードバランサを経由せずサーバへ直接通信が発生するため対応します。

知っていれば沼に嵌ることはなかったのですが、今回の構築で一番の壁となったのは先ほど紹介したEphemeralポートです。
先ほど、Windowsでは「49152 ~ 65535」と紹介しましたが、AWSでは「1024 ~ 65535」の開放が推奨されています。

セキュリティグループ同様にアクセスされると困るポートには接続元IPを指定し、設定を少し厳しめにしています。
なお、ネットワークACLの基本は全アクセス拒否となり、必要なポートのみアクセス許可する設定方法を取ります。
ルール番号が若い（数字が小さい）番号が優先されますので、アクセス拒否設定は一番最後です。

DA用、ロードバランサ用のネットワークACLもセキュリティグループに設定したポートに合わせて設定しましょう。

サーバ側でRDPセッションを2つ以上許可すると、スクリーンロックが効かなくなる

RDPで接続する場合は単一セッションでの利用がデフォルトですが、複数人で環境構築ができなかったため一時的に管理者セッションを2つに変更していました。
この状態でDAのスクリーンロックを利用すると、ツール側はロックしようとしている（スクリーンロックの文字がグレーになる）が、管理者セッションが1つではないためログイン画面へ遷移しない事象が発生しました。

もちろん、スクリーンロックが正常に動作していないため、DSからアクセスしてもDAのレコーダービューには何も表示されません。
サーバ構築作業の完了時はRDPの管理者セッションは1つに戻しましょう。

MCのDB設定でIPアドレスが使えない 

ログ/ユーザDB等の外部から参照する可能性のあるDB設定の際に、ホスト名にAWSのパブリックIPを入れると接続テストが失敗します。
ループバックもしくはプライベートIPでは問題なく成功しますが、自宅等で開発する場合はインターネット越しにアクセス（DNS名前解決）ができないため、DS上ではDB接続エラーとなります。

こちらを解決するには、パブリックIPではなくパブリックDNSを指定する必要があります。
DAのホスト名設定と同じですね。

ちなみに、AWSのVPC内のEC2等からパブリックDNSでアクセスが発生した場合、一度インターネット（≒パブリックDNS検索）になると考えられますが、そこはAWS！！
VPC内のアクセスはプライベートDNS/IPでアクセスされる仕様となっているため、インターネットを介さずに高速で通信できます。 

AWSのEC2にはOfficeをインストールできない 

EC2で構築当時、調査不足で買い切りのOfficeライセンスでも問題ないかと思っていました。
実際、導入しようとするとWindowsServerのインストーラーが見つからない…という問題に直面しました。

どうすればいいのか確認したところ、そもそも所有しているハードウェア（PC/サーバ）にしかOffice製品(365を含む)はインストールできない規約となっており、EC2等の仮想環境はクラウドベンダーがハードウェア（サーバ）を所有しているため、利用しているユーザには使用権はあっても所有権がなくインストールできない結果となります。

AzureのVMではOffice365の利用ができるようなので、どうしてもExcelやVBSを実行したい場合はそちらを利用することを検討しましょう。
弊社としては、スプレッドシートを利用するようなロボットばかり（むしろ、それしかないような…）のため、影響も少ないと判断し諦めました。
※実際は諦めたわけではなく、EC2をリザーブド契約で運用しており、今さら変更できないためです。

 最後に 

今回は、AWS構築編の続編でしたが、いかがだったでしょうか。
とりあえず動く環境を構築して（それでも大変でしたが）簡単な動作確認で済ませてしまっていたため、いざ本番用に調整すると課題が山積みでした。
また、VPCやサーバ構築方法も一部変更したこともあり、より深みに嵌った感じではありましたが、そちらについてはRPAT社が推奨している方法ではないため紹介していません。
気になる方がいらっしゃれば、BizRobo!CAMPUS!!等にも参加していますのでお気軽に質問いただけばと思います。

最後まで読んでいただきありがとうございました。