HomeRPAブログページBizRobo!活用例【続】AWSでBizRobo!Basicが動く環境を構築してみた

BizRobo!ブログ

こんにちは。

 自称)BizRobo!エンジニアのもりりんです。

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

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

 

 問題点 

考える猫.png

 問題を1つ解決すると、関連した問題が出てくるとイタチごっこのようでしたが、なんとか解決できました。
 ただし、下記に上げた問題ですが、4に関しては解決できておりません。
 Officeを解決したい場合、Microsoftのライセンス問題が根深いためAWSではなくAzureで構築することをおすすめします。

 

  1. AWSのネットワークACL/セキュリティグループの接続ポートを最低限に抑えると、MC/RDPもアクセスできなくなった
  2. サーバ側でRDPセッションを2つ以上許可すると、スクリーンロックが効かなくなる
  3. MCのDB設定でIPアドレスが使えない
  4. AWSのEC2にはOfficeをインストールできない

 

 それぞれの問題について 

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


  こちらは題名の通り、セキュリティ対策で開放するポートを必要な分だけ設定すると、アクセスができなくなる問題でした。

 イントラ内に存在するMCサーバでネットワーク上に開放が必要なポートは、以下です。

  • 3306
  • 8080
  • 3389

 DAサーバで開放が必要なポートは以下です。

  • 3389
  • 49998
  • 49999

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

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

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

ポート紹介抜粋Wikipediaのポート番号一覧の目次抜粋
引用:TCPやUDPにおけるポート番号の一覧
フリー百科事典『ウィキペディア(Wikipedia)』 

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

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

  • ネットワークACL  :外(インターネット越し)から 構築したネットワーク にアクセス制限を追加する 
  • セキュリティグループ:外(インターネット越し)から 構築したEC2(サーバ) にアクセス制限を追加する

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

AWS設定イメージ

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


MCセキュリティグループMCサーバのセキュリティグループ設定例

 

 なお、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」の開放が推奨されています。

aws 一時ポートネットワークACLの一時ポート設定例の抜粋
引用:ネットワーク ACL を使用してサブネットへのトラフィックを制御する
AWS

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


MCネットワークACLMCのネットワークACLの設定例

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

 

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


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

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

 参考:【図解】Windows Server 2019:リモートデスクトップ 複数セッション許可設定

 

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


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

ログ ホスト参考MCのDBホストの設定例

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


パブリックIPAWSのEC2インスタンスの概要

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

AWS VPC質問Amazon VPC のよくある質問の抜粋
引用:Amazon VPC のよくある質問
AWS

 

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

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

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


aws office制約ライセンシング – Microsoft Officeの抜粋
引用:AWS と Microsoft に関するよくある質問
AWS

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

 

 最後に 

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

 最後まで読んでいただきありがとうございました。
 また、次回をお楽しみに。

 

<RPAの導入につきまして>

 本Blogは、お役に立ちましたでしょうか?

 RPAは、一般的な業務システムとは異なり、PoCを実施し、導入・運用開始で終わりでははありません。
 導入時点からようやくスタートです。
 業務効率化、人員最適化等の目標に応じた計画策定や人員配置、自動化ロボットの開発・運用といったPDCAサイクルが必要です。
 弊社では、貴社の課題に適した自動化プランのご提案や開発者育成研修も実施し、貴社と並走したサポートをご提供いたします。

 お気軽にお問い合わせください。
 BizRobo!や弊社サポートについて詳しくはこちら >>> サービス紹介 - BizRobo! (自動化ツール)

 

大阪本社
〒541-0056
大阪市中央区久太郎町2-2-7 山口興産堺筋ビル3階  アクセスマップ
TEL:06-6266-0440   FAX:06-6266-0450