Power Virtual Serverのリソース変更にかかる時間

# はじめに
IBM Cloudから利用可能なPower Virtual Server(以下Power VS)は、AIXやIBMiといった従来AS/400と呼ばれていたPowerをCloudを通じて利用可能になるサービスです。
個人的に魅力と感じているのはDynamic Prtitioningを用いた、利用しているPower VSのサーバーリソース(CPU/メモリ)をオーダー時点の8倍～1/8倍まで、サーバーを稼働させながら変更できる、という点です。
PowerVSは利用しているサーバーのCPU/メモリで課金されるのと、Suspend Billingに対応していないので、サーバーをシャットダウンしていてもサーバーに設定されたCPU/メモリの課金が発生します。
従って、費用をなるべく最小化して運用するためには、 `使っていない時はリソースをなるべく小さくしておく` ことが重要になります。

# リソースの最適化って？
適当に描いたグラフですが、例えばシステムのメインの利用時間が9時から18時のビジネス時間に集中している場合、18時から夜中時間中はリソースをあまり使わない状態が想定されます。現実的にはバッチ処理を動かしてるケースもありますが、バッチ処理は専用サーバを設けてるケースもあるので、ここでは割愛します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/651598/aea09fa1-b6d8-a5f4-2dde-a7496e9da4d6.png)

通常サーバは必要とされる処理能力のMaxを想定して購入、オーダーするので遊休リソースがどうしても出てきます。クラウドでは柔軟にリソース変更ができるという話も聞くことが多いですが、リソース変更時にサーバーの再起動が発生するので、必要なプロセスが正しく立ち上がっているかといった確認が必要なので、できれば稼働したままリソース変更可能であれば、プロセスの確認が不要で便利ですよね。

先ほどのグラフで8時-18時の10時間は必要リソースのMAXを用意しておき、18時-0時-8時の14時間は必要リソースの半分にできる、と考えてみましょう。Power VSで2コア(16vCPU※上限無し共有コア)、32GB RAMが最大リソースとした場合、ストレージを抜きにした費用で$0.81/時間が発生します。
この環境を1か月間(31日)最大リソースのままにすると `$0.81 × 744h = $602.64` の費用がかかりますが、上記の通りリソースの最適化を行うと`$0.81 × 744h × (10h/24h) = $251.1、 $0.41 × 744h × (14h/24h) = $177.94`、合計 `$429.04`の費用になり、最大リソースのままにすることに比べると3割くらい費用低減ができます。もし、土日の稼働が低ければもっと削減できることになります。

# どうやってリソース変更を行うのか
大きく方法は2つあります。
## IBM Cloud ポータルで変更する
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/651598/7376048a-5a6e-e9f2-2c3d-8000096240c1.png)
ポータルでインスタンスを表示している状態で、右上のEdit(編集)からコア数とメモリサイズを指定して変更できます。
訓練や災害対策といった特定のタイミングだけ実施するのであればGUIでも良いですが、毎日この操作はやってられないですね。

## APIで変更する
[APIリファレンス](https://cloud.ibm.com/apidocs/power-cloud) でサーバー(インスタンス)の[Update用のAPI](https://cloud.ibm.com/apidocs/power-cloud#pcloud-pvminstances-put)があるので、それを利用して指定したサーバのリソースサイズを変更可能です。

## 変更における注意点
Power VSのリソースサイズの変更は必ずしも常に成功するものではありません。
以下の要因でリソースサイズ変更が実現しないケースがあります。これらは実行時にエラーになるものもあれば、実行した後に変更に失敗したとエラーになるケースとあります。
例えば変更が実現しないケースでは以下があります。
- サーバーのリソースサイズを縮小しようとした際に、サーバー自体がコアやメモリを使用しており、開放できない
- サーバーのHealthのステータスがOKではなくWarnning等になっており、変更要求を受け付けられない
- Power VSは物理筐体から切り出された論理区画(LPAR)として提供されますが、物理筐体側にリソース割り当ての余力が無い

これらに注意してリソース変更を実施頂ければと思います。

# リソース変更にかかる時間
## 計測方法
- APIを利用してリソースサイズ変更要求を実行
- APIの応答でAccepted(202)が返ってきたhttpヘッダーの時間をスタート時刻として記録
- PowerVSの実機では5秒起きに `lparstat`のコマンドを実行してサーバに割り当てられたリソースが変更された時刻を記録
- 別途APIで対象サーバーのリソースサイズの取得を無限ループで実行し、API(ポータル)で割り当てられたリソースが変更された時刻を記録
- 同等の変更を5回実施する
- 対象のPowerVSはコアにUncappedの0.25コア、メモリ2GBでオーダーしたものを利用

## 計測結果
### メモリサイズ変更
#### 2GB → 3GB
|試行No|PowerVSの実機で<br>変更を検知するまでの時間(秒)|APIで<br>変更を検知するまでの時間(秒)|
| ---- | ---- | ---- |
|1|31|89|
|2|39|67|
|3|41|122|
|4|53|118|
|5|35|88|

#### 3GB → 2GB
|試行No|PowerVSの実機で<br>変更を検知するまでの時間(秒)|APIで<br>変更を検知するまでの時間(秒)|
| ---- | ---- | ---- |
|1|33|84|
|2|30|64|
|3|36|71|
|4|40|64|
|5|30|69|

#### 2GB → 16GB
|試行No|PowerVSの実機で<br>変更を検知するまでの時間(秒)|APIで<br>変更を検知するまでの時間(秒)|
| ---- | ---- | ---- |
|1|28|49|
|2|51|95|
|3|36|100|
|4|43|112|
|5|32|71|

#### 16GB → 2GB
|試行No|PowerVSの実機で<br>変更を検知するまでの時間(秒)|APIで<br>変更を検知するまでの時間(秒)|
| ---- | ---- | ---- |
|1|38|105|
|2|49|114|
|3|34|69|
|4|36|77|
|5|29|76|

### コアサイズ変更
#### 0.25コア → 0.5コア
|試行No|PowerVSの実機で<br>変更を検知するまでの時間(秒)|APIで<br>変更を検知するまでの時間(秒)|
| ---- | ---- | ---- |
|1|25|77|
|2|25|70|
|3|33|87|
|4|30|76|
|5|41|83|

#### 0.5コア → 0.25コア
|試行No|PowerVSの実機で<br>変更を検知するまでの時間(秒)|APIで<br>変更を検知するまでの時間(秒)|
| ---- | ---- | ---- |
|1|26|89|
|2|45|91|
|3|33|89|
|4|38|89|
|5|31|76|

#### 0.25コア → 2コア
|試行No|PowerVSの実機で<br>変更を検知するまでの時間(秒)|APIで<br>変更を検知するまでの時間(秒)|
| ---- | ---- | ---- |
|1|32|118|
|2|37|91|
|3|26|58|
|4|23|74|
|5|27|72|

#### 2コア → 0.25コア
|試行No|PowerVSの実機で<br>変更を検知するまでの時間(秒)|APIで<br>変更を検知するまでの時間(秒)|
| ---- | ---- | ---- |
|1|28|59|
|2|38|91|
|3|26|80|
|4|27|55|
|5|29|64|

### コアサイズ、メモリサイズ変更
#### 0.25コア → 0.5コア、　2GB → 3GB
|試行No|PowerVSの実機で<br>変更を検知するまでの時間(秒)|APIで<br>変更を検知するまでの時間(秒)|
| ---- | ---- | ---- |
|1|34|84|
|2|40|70|
|3|34|115|
|4|37|109|
|5|26|60|

#### 0.5コア → 0.25コア、　3GB → 2GB
|試行No|PowerVSの実機で<br>変更を検知するまでの時間(秒)|APIで<br>変更を検知するまでの時間(秒)|
| ---- | ---- | ---- |
|1|32|69|
|2|27|87|
|3|33|75|
|4|34|89|
|5|41|63|

# 所感
思ったより適用されるまでは早いかと思いました。実機に反映されるまではだいたい1分以内、API(ポータル)への反映も2分あれば終わったケースがほとんどです。もう少し時間がかかるものかと思っていました。
また、かかる時間を見てると、変更するサイズ量の影響はあまり無さそうに見えます。変更サイズの差が小さいから早いとか、そんなことは無さそうですね。

ただ、ひたすらリソースサイズ変更のAPIを実行していて陥ったのが、リソースサイズの変更要求を行って、PowerVSの実機では変更が適用されて、特にプロセスでエラーが起きたりはしていないのですが、APIでPowerVSのステータスを見ているとHealthが数分ほど `Warnning`になっており、リソースサイズ変更後に直ちに変更し直すという操作が受け付けられないようなタイミングが何度かありました。感覚では6,7回に1回くらいのペースで。
PowerVSのリソースサイズは毎分変更するようなものではないので、あまり気にする必要は無いかもしれませんが、誤ったサイズに変更してしまった後に、改めて目的のサイズを設定しようとするとしばらく待たされる可能性は否めないですね。

# さいごに
PowerVSのリソースサイズの変更は、サーバーを起動した状態で変更できるため便利です。
普通クラウド提供の仮想サーバーはリソースサイズの変更にはマシンの再起動が必要なケースがほとんどなので、再起動後のプロセス確認等、本番稼働しているマシンほどそんなに頻繁に停止させられないので、リソースの最適化はなかなか難しいです。サーバーの起動状態でリソースの増強、また縮小が出来るPowerの仕組みはすごいですね。
このリソースサイズ変更機能をぜひ活用頂ければと思います。