MCバックアップ取得ロボのサンプルを例に、運用観点で「よい」ロボットを考えてみる

## はじめに

前回は Management Console のバックアップ取得方法を紹介しました。

https://qiita.com/ParakeetOnTheHead/items/e65bb4f6c8ce802aa622

その際の `まとめ` で「専用のロボットを作成してもいいですね。」と書いたこともあり、今回はロボット化する場合に `運用観点` で注視するポイントについて考えてみたいと思います。

## ロボット化のパターン

BizRobo! でファイルをダウンロードする方法はいくつかありますが、今回のケースでは主に3つのパターンになるのかなと思います。

#### Pattern#1「ページの読込」でファイルをダウンロード

画面操作による一番オーソドックスな方法です。ブラウザのアドレスバーに指定のURLを入力し、取得したファイルを `一旦ロボットの中に確保` したうえでファイルに書き出します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3090491/4c79a4aa-e9e4-2a40-4136-74b348c28402.png)

#### Pattern#2「REST Web サービス呼出」でAPI経由のファイル取得

BizRobo!内のブラウザ機能を使うまでもなくAPI呼出で直接URLにアクセスし、返ってきた情報を `一旦ロボット内に確保` したうえでファイルに書き出します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3090491/c8709213-6040-f3ef-2a55-f93c1dfde8a9.png)


#### Pattern#3 「ターゲット抽出」でファイルへ直接書き出し

APIとしてやり取りするまでもなく直接URLを指定し、返ってきた情報をファイルシステムに保存します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3090491/c30882eb-d416-3560-a26f-db76bffe13fd.png)


## 上記の3例から運用観点で「よい」ロボットを考えてみる

ロボットの運用をしている側から見ると「よい」ロボットの条件といった場合、以下の３要素がまず思い浮かびます。

   1. 処理負荷が低い（インシデントが少ない）
   1. 実行時間が短い（インシデント時のリカバリーが迅速）
   1. シンプルで小さい（インシデント対応が容易）

`ハイブリット型開発` を採用している弊社にとって運用の責任範囲は「稼働の監視」と「インシデント時の原因切り分け」及び「復旧のための対処」までで、ロボットに原因があった場合の対応・改善についてはそのロボットの所有者（主幹部署）[^1]にお願いします。

「保守・改善」については業務部門の役割として、運用にフォーカスすると「予定外の仕事」を最小化するロボットが「よい」ロボットと言えます。（主観です）

ちなみに「予定外の仕事」というのは以前読んだ DevOps 本に書いてあった4つの仕事の内の1つです。

https://atmarkit.itmedia.co.jp/ait/articles/1602/08/news017.html

今回のケースでは「処理負荷」の観点を例にとり具体的に検討していきます。

### サーバ型集中処理アーキテクチャの注意点

パソコン上で個別に動くロボットと異なり、複数のロボットが同時にサーバ上で動作する場合、サーバのリソース（特にメモリ）を複数のロボットでシェアすることになります。

サーバはパソコンに比べれば広くて頑丈なマンションのようなものですが、かといって無制限に何でも詰め込めるわけではありません。（個別にはその広さを意識する必要がないほど余裕ではありますが。）

細かなルールで縛る必要はありませんが、シェアハウスでの生活のように最低限のガイドラインは設定しておくのがいいと思います。

例えば、メモリ負荷で言えば
- ファイルのダウンロードはできるだけ直接ファイルシステムに書き出しましょう。
- POIにExcelファイルを読み込ませる場合には単票/1シートのサイズを原則としましょう。

など。

またサーバ構成の観点で言えば、ロボットの実行が一か所に集中してしまわないようにクラスターの配下に複数の RoboServer をぶら下げて負荷分散するという手もあります。

社内で運用している `感覚` で言えば、2KCU 毎に RoboServer を分けてしまってもいいかもしれません。サーバ型のソリューションといっても基本的に BizRobo! はスケール・アウト 型のアーキテクチャなので、RoboServer へのヒープ設定も 4G～8G 程度にしてインスタンスを複数稼働するのがいいのでは？と思っています。[^2]


### 運用視点でお勧めできるロボットは「ターゲット抽出」のみ

といったところで、お勧めできるロボットの実装パターンは「ターゲット抽出」です。
「ページの読込」も「REST Web サービス呼出」もバックアップデータを一度ロボット内に取り込むことでメモリを消費してしまうので。

:::note warn
念のためですが、Webページを読み込んだり、APIの呼び出しをすることに問題は全くありません。今回のケースでは割と大きなサイズのファイルをダウンロードするという観点で見解を示しています。
:::

ちなみに基盤・運用セクションで運用しているロボットが160個程度の環境では、バックアップファイルのサイズは16MBでした。

全く目くじらを立てるほどのサイズではありませんが、リソースを有効に使うという観点がない場合、生活習慣病の様にリソースの消費がどんどんと増えていってしまい、気が付くとメタボリックな環境になってしまうこともあるので、習慣化が重要だと思います。

メタボ防止のための定期健診として、是非 `RobotAdviser` による定期的なモニタリングを推奨いたします！:stuck_out_tongue_winking_eye:


:::note
ちなみに、Chromiumを使った実装であればブラウザを通じた画面の操作でも直接ファイルシステムに保存をする形式であるため、「ターゲット抽出」と同じ効果を得られます。
:::

## サンプルロボット

上で紹介したロボットのソースファイルを GitHub に登録してますのでよろしければご利用ください。(v10.4.0.1で作ってあります）

https://github.com/kiban-unyo/BackupMC-Robot

## まとめ

`「よい」ロボット` について個人の感想を書いてみました。

[^1]: 基盤・運用セクションでも多くのロボットを主幹しており、そういったものの保守・改善については DevOps の観点から常に自分たちで改善に取り組んでいます。

[^2]: サーバといっても可用性確保の観点からはマシン自体も別として個別に RoboServer を構築するのが正しいとは思いますが、処理効率性（Full GC時のStop the World最小化や、RoboServer 上で動く多くのロボット処理に対するスイッチングコスト低下）の観点からは同一マシン上に実行ポート番号を分けた複数の RoboServer を起動して処理分散するというのは一定の効果があるのでは？と思っていたりします。（どの程度の処理効率変化があるかは検証していません。印象の話です）

## 追記：2024年8月15日

本件サンプルロボットを正式に MyBizRobo! からダウンロード可能なロボットとして整理しました。
内容はほぼ同じですが、よろしければご活用ください。

https://my.bizrobo.com/product/detail/5d578b3c-1f46-47b2-9774-010fc08a041c