オンプレミスへの回帰について

前回の記事「クラウドへの移行について」と真逆のタイトルです。

ここ3年ほどで何度か『クラウド移行したけど運用コストが予想より高かったのでオンプレに回帰した』という趣旨の記事をネット上で見かけることがありました。しかしそれらの記事にはどれも、具体的にどんな問題があったかについて記述されていません。具体的でないので、記事そのものが疑わしいと感じていました。

「クラウドへの移行について」の最後に紹介した「NTTぷらら、映像配信のストレージをAzureからオンプレミスに移行、ストレージ利用コストを削減」のような一部だけ回帰のケースは時々見ます。これらの記事には具体的な記述があり著者も明確なので、事実であろうことを疑う必要もないでしょう。クラウドだっていつでもどんな状況でも優れているわけではない事例です。

最初に記したような完全回帰の記事にはなぜ具体的な記述がないのかですが、こういった記事は、世の中のクラウドへの移行について行けないあるいはクラウド移行したくない事情を持っている一部の人達のプロパガンダだと予想しています。だから具体的な記述がないのではないでしょうか。

また、前回の記事「クラウドへの移行について」にも記したように、マイグレーションしただけではランニングコストが高くつきます。最低限のマイグレーションだけしてクラウドへの移行が終わったと勘違いしてそのまま使い続けて、「高い」と間違った評価をしている可能性も高いと思います。

ランニングコストも低く抑えたいなら、クラウドに特化するモダナイゼーションも必須です。これはコンテナ技術を使ってスケーリングに対応することとは異なります。

クラウドへの移行について

今更な気もするのですが、クラウドでの開発にかかわっていながら認識のない技術者も意外と多いようなので、記事にしてみます。

クラウドへの移行方法

オンプレミスやレンタルサーバからクラウドへの移行については、大きく2つの方法があります。

1. マイグレーション
2. モダナイゼーション

マイグレーション

既存のシステムをできるだけそのまま移行あるいは、既存の製品や技術をできるだけ利用して移行する方法です。新しく習得しなければならない技術・知識が最低限で済み、既存の資産もある程度再利用できるので、移行にかかる期間・コストが小さくなります。

一度クラウドへの移行を果たした後も、別のクラウドへの移行が行いやすい利点もあります。GCPで言えばGCE/GKEなどのIaaSと、オープンソースソフト(OSS)への依存度が高くなります。

その反面、クラウドの持つ特徴・能力を限定的にしか利用できず、運用が始まってからのコストが高くなり、自由度も限定的になります。構成によっても違いますが、運用においてはメンテナンス要員が必要となることも珍しくないと思います。

初期コストを削減する代わりに、運用コストに目をつむるような方法です。

コンテナ技術が利用できるようになってからクラウドの利用が多くなったのは、コンテナにより既存の製品・技術を使いながらもクラウドによるスケールアウトのメリットを享受できるようになったからという面があります。コンテナの中身がレガシーの塊になっているのは、『マイグレーションあるある』じゃないでしょうか。マイグレーションしか経験がないのに「クラウド使えます」とか言ってるようでは、技術者としては中途半端です。

モダナイゼーション

クラウドでの実行を前提としたクラウドネイティブな構成にすることにより、クラウドの特徴・能力を大きく享受できるようになります。さらに特定のクラウドに限定するなら、享受できる利益は最大限にもできます。最適なサービスを選択できれば運用コストは少なく、メンテナンスフリーにできる範囲も広くなります。新しく一から開発する際には、魅力的な選択肢になります。

近年リリースされたサービスではクラウド内のサービスの連携を実現するものも少なくないので、OSSとかは蚊帳の外ということもあります。そういった悲劇に遭わなくて済む利点もあります。IaaSへの依存が少なくなり、PaaS/SaaSの利用が多くなります。

反面、クラウドについて新しく知識・技術を習得する必要がでてきます。既存の資産・技術も置き換えが必要になるものも珍しくありません。「GAEインスタンスの起動時間」でSpringが使い物にならいことに触れているのは、その一例です。また特定のクラウドに限定した作りを選ぶと、他のクラウドへの乗り換えが困難になるクラウドロックインが発生します。

初期コストの増加を覚悟する代わりに、運用コストは最適化できるようになります。

GKEの様なコンテナ技術ももちろん利用できますし、GAEのように特に気にせずそれを利用できるサービスもあります。クラウドネイティブな開発が出来るようになれば、「クラウドを使える」技術者と言えると思います。

移行の実際

完全な新規開発ではモダナイゼーションで始めることもありますが、既存システムの移行となるとマイグレーションが多いと思います。マイグレーションで最短期間で移行後に、運用しながら少しずつクラウドネイティブにモダナイズしていくのもお勧めです。

また完全移行ではなく一部のみを移行する場合もあります。クラウドの利用料金は「使った分だけ」ですが、単価が高め設定の機能の利用が多かったり、単価が段階的に安くなる料金体系でない場合は、クラウドにすべてを移行しても運用コストが下がらないケースがあります。「NTTぷらら、映像配信のストレージをAzureからオンプレミスに移行、ストレージ利用コストを削減」のようなケースです。

マイグレーションで移行してそのままというのはお勧めしません。ランニングコストが高く、クラウドに移行した効果が得られにくいからです。「将来また別のクラウドに移行するかもしれないから、クラウドロックインの発生しにくい方法を選択したい」という考えもあるかもしれませんが、「別のクラウドに移行」する未来が来る可能性なんてどれほどあるんでしょう。

データストアの選択

世の中には データを保存しておく製品にも、いろいろと選択肢が用意されています。GCPでも目的に応じて特徴の異なる複数のサービスが用意されています。その中でもBigQueryって特徴的で判りやすいと(個人的には)思っていたのですが、最近になってGCPにかかわりながらもBigQueryがどういうものなのかを未だに知らない人に遭遇しました。

ここでGCPのデータの保存目的に使えるサービスを比較しておきたいと思います。

一覧

GCPに用意されたサービスの一覧です。

名称	略称	概要	スケーラブル	マネージド
Firestore	(特になし)	NoSQL、ドキュメント指向データベース。	〇	〇
Cloud SQL	(特になし)	SQLのリレーショナルデータベース。	△	〇
Cloud Spanner	Spanner	SQLのリレーショナルデータベース。	〇	〇
Cloud Bigtable	Bigtable	NoSQL・低レイテンシのデータベース。	〇	〇
Memorystore	Memstore	オンメモリで高速動作。	〇	〇
BigQuery	(特になし)	検索に特化したデータウェアハウス。	〇	〇
Cloud Storage	GCS	非構造化データ用のストレージ。	〇	〇

「略称」はGoogleが決めた正式なものではないですが、開発者の間でよく使われている呼称です。

「マネージド」の〇はフルマネージド、△はフルではないマネージドを表します。

これら以外にもFirebaseのサービスもあるのですが、それらに関しては割愛します。

各サービスの特徴

サービスを比較・選択するうえで参考としていただけるように、ざっくりと説明します。詳細はGoogleの各サービスをご覧ください。

Firestore

スケーラブルなので負荷が増えても重くなる心配がありません。むしろアクセスが少ないと優先順位が下げられて待ちが長くなる感じさえあります。フルマネージドなのでメンテナンスフリーです。

スキーマレスでドキュメント指向です。自分で各ドキュメントの構造を同じにして使えば、テーブルとして使えます。検索用のインデックスが付いた連想配列の様な感じですが、インデックスによる検索機能は貧弱です。柔軟な検索が必要なら、ElasticSearchやGAEのSearch APIと組み合わせる必要があります。

強整合性でトランザクションにも対応しています。

費用は主に保存容量に対して発生し、無料枠もあるので、ランニングコストは低めです。

SQLしか経験のない方には理解しにくいかもしれませんが、「Not only SQL」なデータベースです。

過去には似たようなDatastoreというサービスがありましたが、それが廃止されてFirestoreのDatastore互換モードとなりました。Firestoreにはネイティブモードもあり、こちらはドキュメントを階層構造にすることもできます。

Cloud SQL

MySQL/PostgreSQL/SQL Serverのいずれかから選んで使用します。これらを自分でGCEに乗せなくても、予めGoogleが用意してくれていると理解すればいいと思います。

なので利点も欠点もMySQL/PostgreSQL/SQL Serverを引き継ぎます。スケーリングに関しては設定した範囲内に限定され、無限ではありません。幸いフルマネージドでメンテフリーで使えます。

費用は主に保存容量とCPUに対して発生します。CPUはGCEと同等なので、ランニングコストはそれなりに発生します。

Cloud Spanner

スケーラブルなので負荷が増えても重くなる心配なし、フルマネージドでメンテナンスフリー、強整合性と、ここまではFirestoreと同じです。こちらはドキュメント指向でありません。SQLでリレーショナルデータベースを使いたい人にとっては、Cloud SQLとFirestore/Bigtableの「良いとこ取り」の様な感じになります。GCPではコスト以外はほぼ最強ではないでしょうか。

費用は主に保存容量とコンピューティングインスタンスに対して発生します。「Cloud Spanner vs Cloud SQL」も参考になると思います。

Cloud Bigtable

スケーラブル、フルマネージド、NoSQLと、ここまではFirestoreと同じです。低レイテンシが最大の売りでしょうか。

GCPに昔からあるサービスで、他のデータベース/ストレージの基盤となるサービスだと聞いたことがあります。(今GoogleのWeb上のドキュメントを探してもそのような説明は見当たらないのですが、当時詳しい人だったかGoogle日本法人の人から聞いた話なので、嘘ではないはず)

費用は主に保存容量とコンピューティングに使われるノードに対して発生します。ノードは事実上GCEと同じなので、たぶんそこそこかかるはず。

Memorystore

Redis/Memcachedのいずれかから選んで使用します。たぶんそれらをGCPに乗せただけと思います。オンメモリなので速いはず。しかもスケーラブル。

速さを活かしてキャッシュや書き換えの集中するデータの保存に向きます。