AWSでBizRobo!Basicが動く環境を構築してみた - 株式会社ミュートス - MYTHOS CO.,LTD.

 こんにちは。

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

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

 オンプレ環境にBizRobo!サーバを構築している企業様が多いと思いますが、クラウドサービスのAWSを利用した場合にどんな点を考慮して環境構築すればいいのか等の疑問点を解決するために実際に試してみました。
 最新版のBizRobo! ver.11を利用したたため、BizRobo!のロボット実行に必要なサーバ類(MC/RS/DB)とDAの基本構成のみ検証した結果となります。

  

 構築イメージ 

---

 構築した環境は以下のようになります。

 今回の環境は、メインサーバに直接アクセスできない仕様としているため、以下の手順で作成していきます。
 ① VPC関連
 ② DAサーバ（EC2）
 ③ メインサーバ（EC2）
 ④ ロードバランサ（ALB）

 

 各種設定のポイント説明 

---

  ①VPC関連 

 最初にVPCを作成しないと、EC2の作成もできません。
 VPCは複数の設定を組み合わせることで成り立っていますが、1つずつ作成すると複雑で理解し辛いため、VPCを理解できていない場合は一括で作成できるツールを利用しましょう。

 外部アクセス可能なパブリックサブネットを3つ持ったネットワークを構築します。
 3つのサブネットはインターネットにアクセスできるよう「Internet Gateway」に接続し、ルートテーブルを設定しておきましょう。
 今回は、以下のようにVPCを設定しました。

サブネット①②にはロードバランサを、サブネット③にメインサーバとDAサーバを配置する予定です。

 

 ②EC2（DAサーバ）

 次は、DAサーバをサブネット③に構築します。 
 DAサーバは、推奨スペックよりも少し低めの「t3.large」の汎用タイプを利用します。

 選択するWindosOSは、Windows Server 2019 DataCenter版です。

 

 ネットワーク設定は、先程作成したVPC/サブネット③を選択し、自動割り当てパブリックIPが有効になっていることを確認しましょう。
 無効の場合、リモートデスクトップ接続（以降、RDPと呼称）でアクセスできなくなります。

 

 一番重要な設定は、セキュリティグループです。
 初期設定だとアクセス制限もかかっていないため、自由にアクセスできてしまいます。
 そのため、アクセス元のIPアドレスや利用できるポートを制限します。
 今回は、VPCのデフォルトSGと3389（RDP）、49998（DA）、49999（DA）の3つを追加したセキュリティグループを新規作成して指定します。 
 ※ 49998（DA）、49999（DA）は、外部NWの起動しているDSからDAサーバに接続しない場合は不要です。

 EC2が起動したらRDPでログインし、Windows初期設定を済ませてしまいましょう。

•  日本語の言語パックをインストール（再起動が必要）
•  タイムゾーンを日本に変更
•  WindowsUpdateを実施
•  Admin権限を持ったユーザの作成し（以降は作成したユーザでログイン）
• 他、必要に応じて必要な設定

 諸々の設定が終了したらユーザでログインし、DAをインストールします。
 DAの接続設定は、メインサーバを構築してから実施しましょう。

 

 っと、思いきや！
 このままDAを利用しようとすると、実は「WebClient」エラーをログファイルに出力し続けています。
 私が見たときは、????で文字化けした状態でした。
 このままの状態でも使えるみたいですが、気になる方は下記のツールをインストールすると直ります。

 

 コントロールパネルまたはサーバーマネージャーの「役割と機能の追加」から「WebDAVリダイレクター」をインストールします。
 途中で再起動が必要なため、表示されたメッセージ通りに進めてください。

次はメインサーバを作成しますが、メインサーバには直接アクセスできないためDAサーバを踏み台として利用します。

 

 ③EC2（メインサーバ）

 メインサーバには、RPAT社が公開しているTomacat構成のセットアップマニュアルに従って「MC/RS/DB」をTomcat経由で利用します。
 メインサーバは、推奨スペックに準じて「t3.xlarge」の汎用タイプを利用しました。 

 ①で実施したDAサーバと同様にEC2の作成、Windowsの初期設定を済ませ、必要なツールのインストールと設定変更してください。
 特に変更する箇所がない場合は、RPAT社が公開しているTomacat環境構築マニュアルに従って作業するだけで問題ありません。

 メインサーバの構築で問題になることは、「外部NWからどのように接続するのか」と「アクセス制限を管理するセキュリティグループの設定」です。

 外部NWからどのように接続するか

 まず1つ目の「外部NWからどのように接続するか」ですが、Tomacat構成だとデフォルトでは8080ポートで稼働します。
 しかし、外部NWからのアクセスは、HTTP（80）or HTTPS（443）を利用するため、そのままの8080ポートではアクセスできません。

 いくらアクセス制限しようともAWSは外部NW上に存在するため、通信が暗号化されないHTTP（80）でアクセスするには不安があります。
 そのため、HTTPS（443）でアクセスできる方法を模索した結果、今回はロードバランサを利用することにしました。
 AWSのアプリケーション向けロードバランサ（ALB）は、HTTPS（443）に必要なドメインとSSL証明書をAWSのDNSサービス（Route53）と連携させることで簡単に設定できます。

 既にドメインを持っている場合、ドメインと対応するSSL証明書があればAWSに簡単に取り込みが可能です。
 持っていない場合は、Route53で格安で利用することが可能です。（ .net や .com であれば$12/年、ドメインに拘りがなければ .link は$5/年で利用可能） 

 アクセス制限を管理するセキュリティグループの設定

 セキュリティグループは、各サービス単位にIPアドレスやポートのアクセス許可制限を追加できます。
 メインサーバにはVPC内のみアクセスな可能な設定にしておくと、外部からアクセスする方法をロードバランサ or DAサーバ経由のみに制限できます。
 VPC内間のみアクセス可能なセキュリティグループは、VPCを作成したときにデフォルトで1つ自動で作成されたものを利用します。

 上記の設定によりメインサーバへのアクセスは、DAサーバからのRDPを利用します。
 開発PC → (RDP) → DAサーバ → (RDP) → メインサーバと、経由が多くなるためこういった作業に慣れるまで開発PCでは操作しづらくなるかもしれません。

 そのような複雑な作業が嫌な場合は、1度DAサーバのように直接アクセスできるEC2を作成し、全てのセットアップが完了させます。
 その後、バックアップイメージ（AMI）を作成しバックアップから目的のEC2を作成すると、バックアップした環境が復元されるためTomcat等のIPアドレスが変更になった差分を調整するだけの簡単作業になるかと思います。

 ④ロードバランサ（ALB）

 ここまでの作業で、メインサーバ内のブラウザでMCにアクセスできることが確認できます。
 しかし、自身の開発PCからアクセスできないことにお気づきでしょうか？

 既に説明していますが、メインサーバで動作しているTomcatにアクセスできるポートは 8080 となっています。
 インターネット越しのアクセスは、特別に設定しない限りHTTPかHTTPSでのみアクセス可能となっており 8080 は対象外です。
 また、メインサーバは直接アクセスができないようにNW構築しているため、ポートを変更してもアクセスできません。

 そのため、今回はAWS内にあるサービスの1つである「ロードバランサ（ALB）」を活用しています。
 構成説明で記載していましたが、①MCへのアクセスをHTTP or HTTPSに制限でき、②HTTPSへの変更がAWS内で完結できるため採用しました。
 という理由ですが、HTTPSの利用はドメイン/SSL証明書の準備に社内調整が必要なため検証ではHTTPを利用しました。

 ALBとEC2を繋ぐために「ターゲットグループ」と呼ばれる通信の転送設定を用意し、ALB（80）へのアクセスをメインサーバ（8080）に転送させます。
 ALB→EC2間のアクセスはVPC内での通信、すなわちセキュリティグループで設定したアクセス制限内の通信となるため安全にアクセスできます。

 

 設定が完了したら、ロードバランサで提示されているDNS名でアクセスし開発PCのブラウザでMCが表示できるか確認しましょう。

 最後にDAサーバのDA接続設定を入力し、MCのデバイス項目に正常に認識されるか確認して完了です。

 最初の完成イメージを再掲

 躓いた点 

---

 今回の構築で躓いた点は、2つです。
 どちらもAWSの仕様理解が足りなかったため発生したことなので、きちんとドキュメントには目を通す、チュートリアルを試す等、基本的なことは抑えましょう。 

 

 DAサーバからメインサーバへRDPでアクセスできない

 VPC内にあるEC2間のアクセスは、AWSのプライベート領域に存在するため外部からアクセスできず、特に設定しなくても勝手にできるものだと思い込んでいました。
 Qiita等のブログを読み漁り全て試して行くことで、VPC内でもセキュリティグループの設定が必要だったことに気がつきました。
 簡単に設定できる方法は、VPC作成時にデフォルトで作成されるセキュリティグループなので忘れないように配置しましょう。

 メインサーバからDAは認識されているが、開発PC内のDSからDAへアクセスできない

 こちらは、シンプルな理由でした。
 オンプレ環境では、 社内NWまたはVPNでのアクセスとなるため各社のインフラ部門でアクセスできるように整えられているかと思います。

 しかし、今回はAWS上に全てを構築しているため、EC2のプライベートIPではインターネットの壁を超えることはできません。
 そのため、DAサーバのEC2ダッシュボードで確認できるグルーバルIPまたはDNS名を利用します。

 DA接続設定画面で入力するIPアドレスは、上記画像で確認したDAサーバ自身のパブリックIPv4アドレスまたはパブリックIPv4DNSを入力しましょう。

 

 運用コスト 

---

 AWSでのBizRobo!環境の構築について説明しましたが、気になるのは運用コスト（と、初期コスト）だと思います。
 AWSの請求はドルベースのため、為替レートにより請求額が月々で変動することご注意ください。

 AWSで長期的にEC2を利用する場合、EC2インスタンスの年間契約（リザーブドインスタンス）を利用することで費用を抑えることが可能です。
 オンデマンド（通常の利用パターン）に比べ、3割ほど安く利用できます。（選択したEC2のスペックや契約期間等で割引率が増えるかもしれません）
 AWSで見積もりツールが公開されているため、見積もりした結果は以下となります。
 AWS 料金見積りツール

 まずは、オンデマンドの見積もりです。
 月額は、約354ドル（5/8時点のレートで46,335円）となり、年額だと約4,249ドル（5/8時点のレートで556,139円）とかなり高額となります。

 続いて、リザーブド契約の見積もりです。
 月額は、約266ドル（5/8時点のレートで34,817円）となり、年額だと約3190ドル（5/8時点のレートで417,539円）となります。
 オンデマンドよりも約12,000円/月、140,000円/年の節約となるため、EC2はリザーブド契約で利用するほうが断然お得と言えます。

 なお、今回は前払いなしとしていますが、円高のタイミングで前払いしておけばトータルコストは安く済むかもしれません。

 最後に 

---

 今回は、いかがだったでしょうか。
 BizRobo!をクラウド上に独自に構築されている企業様は少数だ思いますが、公式での情報もあまり開示されておらず未知の部分が多くあり、少しでも参考になればと公開しました。
 しかし、AWSの仕様や手順を細かく書くと結構なボリュームになってしまうため、端折りながらの説明になってしまったことご了承ください。

 できるだけ予算をかけたくない、けれどもセキュリティは担保したいというよくあるパターンの構成を想定して作成しました。
 今回は2台サーバ構成したが、PoCや最小構成でスタートしたい場合は、メインサーバにDAを兼用させることで1台構成も可能です。
 ただし、1台構成はRPAT社では推奨されないため検証は念入りに。

 他にもメインサーバにRDPでアクセスさせたくない場合、Windows追加オプションのOpenSSHをインストールし、ファイアウォールを調整することでSSHアクセスも可能ですので色々とお試しを。
 参考サイト：Windows Server 2019 EC2インスタンスでSSHサーバーを有効にする

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