日本郵便のコスト削減例を見て
これまで物理サーバーを利用していた企業が今後パブリッククラウドを利用するかどうか、という商談でありがちな話なので記事にしておきます。
日本郵便は2020年1月に稼働させる新プライベートクラウド「2020基盤」で、初期コストと5年間の運用コストの合計が従来基盤に比べ82％減の約39億円になる見通しであることを明らかにした。2019年10月現在、テストや、BCP（事業継続計画）に基づくシステム切り替えの演習といった詰めの工程を迎えており、目標としていた大幅なコスト削減が確実になったもようだ。
安くなった理由
76ラックが7ラックになっていて、こんなに物理サーバーの数を減らせれば82%減は伊達ではないよなと思います。利用サーバーを洗い出しCPU使用率やメモリー使用率を調べてみたら全然使われていないことが判明し思い切ってリソースを減らしたと考えるのが妥当だと思います。
私もいろいろと基盤を見ていますが、正直ラック数を十分の一にできるほど利用されていないサーバー基盤を見たことがありません。システム構築時の性能要求と実際の利用時の使用リソースに乖離があるとこうなります。だいたいシステム構築時には5年後でも大丈夫な最大容量にてキャパシティープランニングをしますから、ほとんどが過大仕様だったと言えるのだと思います。
一方で、この新基盤。まだ使い始められていないので、実際に動かしてみたらサーバーリソースが足りずラックがどんどん増えていく可能性もはらんでいますから「5年で82%浮く」は5年経ってみないと真実は見えてこないでしょう。
特にキャパシティープランニングを過小に見積もったときの、運用部隊へのプレッシャーはひどいものです。月初のバッチ処理がなかなか終わらないだの、レスポンスタイムが悪化するだの、前はこんなことなかっただの。そこでリソースを増やす際にはプライベートクラウドなので追加のサーバーを発注したりサーバーラックを用意したり、配線を行なったりと、想定していない運用コストが発生しますし、これは安くありません。
運用部門の人数に余裕があれば、彼らが仕事に困らないという意味で生産性は高いのかもしれませんが限度があります。あまりにもあまりにもだと、またアウトソーシングが潤うのですがそれも追加の運用コストになります。
パブリッククラウドの場合は、これらの運用コストがぐんと下がる可能性があります。パブリッククラウドだと過小に見積もったとしてもリソースを追加で購入することは非常にたやすいことですし、経済的です。逆に過大なリソースを使っていた場合は減らすこともできます。また、必ず使うリソースについては年間予約等を使って安くすることもできます。そしてインターネット利用費用やサーバーラック費用、サーバー保守費用も含まれます。
パブリッククラウドは必ずしも安くない、これは逆に言い換えれば、プライベートクラウドは必ずしも安くない、と同義です。日本郵便の新基盤が本番リリースされた後、どのような軌跡を辿るのか誰もわからないのでどちらに転ぶかはわかりません。
ただ、以前から報道されていた通り、サーバー保守を業界では当たり前とされていた24時間保守から、センドバックの営業時間保守という最低限のものにしていること。また、サーバーベンダーの保守ではなく第三者保守にしていること。面白いのはストレージだけはレベルを下げていないように思います。ここは多分24時間保守のままでしょう。コモディティーな部分と大事な部分を分けているんじゃないかと予想しますし私ならそうします。
そしてIBMのAIXをやめたり、Oracle DBからPostgreSQLに切り替えていること。もう徹底的にやったなという印象ではあります。これはパブリッククラウドでもできることですね。まあIBMはRedHatのサブスクリプション費用でなんとか食いつなげるけれども、端的にOracleはこれから大変だなと思います。そこまで性能要求が高くないデータベースは軒並みOSSに変わっていくのかな・・と。
パブリッククラウド考
このように、日本郵便ならこの方策は一見正しいように見えるのですが絶対ではなく、記事本文中のように本番運用の状況を見ながら次の手を考えるのでしょう。運用部隊が超優秀であるなら、安定運用を実現できてしまうかもしれません。そうすると将来、正しかったと言えるかもしれません。
一方で、「運用部隊」と言っても人の集まりですから、永年に渡って優秀な人が常駐してくれるかどうかはわかりません。日本郵便ぐらい大企業だとまだ確保できるかもしれませんが中小企業だとあまりにも人に依存してしまうので、コストが変わらないならパブリッククラウドの選択肢が有効かと思います。
プライベートクラウドでもパブリッククラウドでも、きちんと管理しないと大変な目に遭うのは同様です。ただパブリッククラウドの方が管理しやすいのは事実です。大胆に抽象化されているのでユーザーはわかりやすい。その分、パブリッククラウド側の運用品質が重要となってきます。ここにコストがかかっているので、一概に本番リリース前に答えが決まっているような捉え方は危険です。
今後は、AWS Outpostsであったり、Azure Stackであったりと言った、パブリッククラウドの仕様をそのままプライベートクラウドで使えると言うやり方も一般化していくでしょう。また、KubernetesやOpenShiftのようなコンテナベースでハイブリッドに利用するやり方も一般化してきます。仮想サーバー世代では今回のようなパブリック or プライベート議論となってしまうのですが、コンテナ世代では全く様子が違ってきます。2019年の今はちょうど端境期にありとても面白い時代で、インフラエンジニアとしては選択を迫られている格好です。幅広く情報収集をする必要があります。最適解は、ケースバイケース、です。
