月一投稿のつもりで始めたブログですが Organization 機能の利用には一定の投稿実績が必要らしいので、しばらくは頻度上げて投稿していきます。

はじめに

BizRobo!はサーバ型のRPA製品なので、多くの場合¹サーバ環境を構築して運用します。
ここでいうサーバとは大きなコンピュータという意味ではなく サービスを提供する役割 のことで、専用のソフトウェアを指します。²

ややこしく思えるのは、サービスを提供する規模が小さい場合には１台のPCに複数のサーバを構築してしまうのが効率的ですし、一定以上の規模（ロボット数や利用者数）が見込まれる場合にはサーバごとにコンピュータを分けて構築することが合理的であったりする点です。

インフラの扱いに慣れていたりBizRobo!をある程度使ったことがある人なら何となく妥当なサーバ構成をイメージできるかもしれませんが、初めてBizRobo!に触れる人にとっては考えるための「とっかかり」がなく不安になるのではないでしょうか。

弊社サポート部門でも顧客からの問い合わせに応じて環境構成の指針を提供したり一緒に考えたりしているようですが、本稿ではまた別の視点として 基盤・運用セクションではどのような考えで、どんな環境を構築しているのか という一例を紹介したいと思います。

以降に示す環境構成は、基盤・運用セクションの業務目的や利用状況に沿った実装であり、一般的な利用を前提として最適かどうかについては考慮していません。

基盤・運用セクションが管理する BizRobo! の実行環境

全社的には複数のバージョン・環境・管理主体が存在していますが、以降では基盤・運用セクションが管理・運用している代表的な１つの環境を見ていきます。³

基盤・運用セクションにおけるBizRobo!の運用方針

現在社内で運用している複数の環境とロボットを、今後この環境に集約していく。
ロボットは24x7で昼夜問わず稼働させる。
ロボットの運用は製品チームへのフィードバックデータの収集と障害発生時の原因切り分けのし易さを考慮し、極力サーバを独立（分離して構築）運用する。
新製品・新バージョンの最初の利用者として、可能な限り最新バージョンにアップデートする。
運用上特に必要でない場合でも、新しい機能は積極的に採用し、評価する。

AWS上での運用について

基盤・運用セクションでは主にAWSを利用してBizRobo!を運用しています。
時々サポート宛に顧客から「クラウドでの運用は可能ですか？」という問い合わせがあるようですが、直接把握している範囲で言えば Azure と AWS にて運用実績があります。

現在は各種サーバをEC2で構築し、リポジトリやログなどのデータベースはRDSを利用しています。
EC2は現在Windowsサーバを使用していますが、今後は一部（RoboServer以外）のサーバについてはAmazon ECSに置き換え、バージョンの切り替えの容易化やメンテナンス性の検証もしたいと考えています。

インスタンスタイプとしては用途・規模により変わってきますが、基本的にBizRobo!ではロボットの多重実行によるメモリ負荷⁴が肝になるのでRoboServerについては「メモリ最適化」インスタンスを前提にするのがいいと思います。

CPUについて特にこだわりはありませんが、プロセッサの種類については Intel または AMD を選ぶのが安全でしょう。EC2には一部 Arm のプロセッサで動くものもありますが、Arm についてはBizRobo! のシステム要件に記載がなく、社内でも試したことがないので。。

CPU性能についてはKCUの上限で処理性能が制限されることの方が多いので気にしていないというのが現状です。ただ、今後画像処理などCPU負荷の高い処理を内部で行うロボットが増えてきた際には適切なスペックについても検証が必要かなと考えています。
一方のメモリは不足するとサーバが例外を吐いてしまうので、大きめに設定しています。

BizRobo! のサーバ構成

サーバの各機能ごとにインスタンスを立てているので、現在4台の仮想マシンで運用環境を構成しています。

運用しているロボットファイルの数は150個弱なので、サイズ的には1台の仮想マシンに同居させることも余裕なのですが、先に述べた運用方針に基づき、サーバごとに独立した構成にしています。

サーバ②上のManagement Consoleには本番クラスターのみが設定されており、ステージングサーバの機能はありません。

サーバ③には3バージョンのRoboServerを登録しています。
現在、他の場所にある v10.7 と v11.1 の環境をこのサーバに移行している最中で、古いロボットを可能な限り手を入れずに移行したかったためです。ロボットはすべて v11.3 のレポジトリに保存されていますが、Management Console から起動された後はロボットのファイルバージョンに応じたRoboServerで処理が実行されます。

サーバ④にはRobot File Systemを構築し、インスタンスのローカルドライブと BOX（FTPS）⁵上のフォルダをロボットファイルシステムとして設定しています。
ロボットファイルシステムはKappletsと並びBizRobo!の特徴的で優れた機能だと思うのですが、いまいち認知度や利用実績が上がっていない印象です。社内でどうやって使っているかについては、改めてブログ記事にまとめたいと思います。

以下、参考までにロボットファイルシステムの紹介動画を張り付けておきます。

新機能として発表された当時の古い動画なので、情報も少し古い点があります。
動画内では利用の前提としてDA端末上でのみ実行するかのような印象を与える部分がありますが、実際はChromiumなどRoboServer側の処理でも利用可能です。

まとめ

開示可能な情報の加減がわからず非常にざっくりした内容になってしまいました。慣れていくうちにまた加筆修正するかもしれません。
ただ、右も左もわからない入門者の方にとっては参考になる情報もあったのではないかと期待します。

具体的には BizRobo! mini 以外の場合 ↩
BizRobo!の場合にはManagement ConsoleやRoboServer、Robot File System、データベース、Robot Lifecycle Managment（Synchronizer）などがサーバとしてよく登場する役割になります。 ↩
実際に現在稼働している社内情報なので、セキュリティや情報保護の観点から最低限の情報共有となりますことはご了承ください。細かい利用サービスや詳細なサーバスペック、ネットワーク構成などについては省略しますが、BizRobo!導入時のヒントになるような情報は極力記載していこうと思います。 ↩
メモリ負荷の考慮が必要なのは複数のロボットが多重に動作するRoboServerについてのみですが、Management Console等他のサーバーについても現在はRoboServerと同じく「メモリ最適化」インスタンスを使っています。今後、サーバの特性を検証しつつこのあたりも調整していくかもしれませんが、優先度は低めです。 ↩
BOXにFTPSでアクセスする方法はこちら→ https://support.box.com/hc/ja/articles/360043697414-FTP%E3%81%BE%E3%81%9F%E3%81%AFFTPS%E3%81%AB%E3%82%88%E3%82%8BBox%E3%81%AE%E4%BD%BF%E7%94%A8 ↩