基幹システムをクラウドへあげるのは簡単ではなかった。ノーチラス・テクノロジーズがクラウドの現実を語る（後編）

基幹システムをクラウドで実現する。その過程でどのような技術を用い、どのような苦労があったのか。小売り流通業である西鉄ストアの基幹システムをAmazonクラウド（以下、AWS：Amazon Web Services）の上で実現したノーチラス・テクノロジーズが、その詳細について紹介したセミナーを5月15日、アマゾンジャパン本社のセミナールームで開催しました。

（本記事は「基幹システムをクラウドへあげるのは簡単ではなかった。ノーチラス・テクノロジーズがクラウドの現実を語る（前編）」の続きです）

和製クラウドでトラブルが続き、やむなくAWSへ移行

インフラについて。やはり和製クラウドベンダのインフラは値段が高い。いろいろ話をして安くならないかと相談したけれど、無理でした。理由は簡単です。データセンターは人を雇っていて、彼らを食わせなければならないので安くならない。

それから自分たちで対応できないんですね。仮想化とかソフトを入れるとできてしまうので、自分でデータセンターを作ってないんです。トラブルになると「ベンダに聞いてみます」とか。最後はわれわれがトラブルシュートして、「このバグにはこのパッチを当ててくれ」と言うと「怖くて当てられない」とか、よく分からない返事が返ってきます。

和製クラウドも、AWSと競争するために機能は必要。とすると、とりあえずソフトウェアを入れて「AWSと同じことができます」と、こうなるわけです。「Hadoopもできます」って言う。

ところがHadoopのクラスタを動かしてみると障害が頻発です。パフォーマンスもすごく遅くなりまして、サーバが落ちてバッチが止まりましたと。

Hadoopでバッチが止まるのは相当なことです。Hadoopは分散環境ですから、ノードが1つ2つ落ちたくらいでは止まりません。このときは3分の2以上のノードが一気に止まるという考えられないことになって。しかも原因究明もこちらで行うことになりました。

全面カットオーバーの前にこれが起きて、極めて不安だと。ユーザーさんと話をして、そこでAWSへ移行することになりました。時間はあと1カ月しかありませんでしたが。

でも私たちは、アンデルセンさんの案件で基幹を経験してやり方は分かっていたので、ギリギリできるかなと。

もうだめだ、というところまで何度もいった

AWSへの移行はうちのエンジニア1人で対応しました。彼はうちのエースで、彼に変わる人材はノーチラスにはいませんし、私は彼ほど優秀なインフラエンジニアに会ったことはありません。

線表を一緒に引いて、3日単位でマイルストーンを決めて、クリアできなければ残念ながら元の環境でやると、お客さんにもそういう話をしながら、3日単位で判断しつつ、いつでも戻せるようにしてやりました。

もうだめだ、というところまで何度もいきました。プレスリリースで書いたような、簡単なものではありませんでした。

で、AWSに移行したのは適切だったのか。結論から言えば適切だったと思います。コストは安いです。使い方を間違えなければコストパフォーマンスは通常の倍はでます。

可用性もやはり高いです。一回あげると落ちません。

EC2とS3。この2つの技術は抜群で、これに代わる技術はほかのクラウドベンダにはありません。特にS3は圧倒的です。

AWSを使って本気でSIをやる、あるいは基幹を運用するのであれば、EC2とS3を徹底的にマスターするべきだと思います。そのうちほとんどのノウハウはS3に近いところにあるのではないでしょうか。

AWS最大のメリットはガバナンス。弱点はサポート

AWSのメリットはコストではありません。たしかにコストは魅力的ではありましたが、いちばん大きいのはガバナンスです。

AWSはいい意味でドライです。われわれがやることに、ああしろこうしろということはありません。一方、既存のSIerのデータセンターでは、必ず政治的になります。そちらのためにこれを準備したとか、それならサーバ買ってくださいとか、値引きするからこうしてくださいとか。

そういったことなく、自分のガバナンスを確保できる。これがAWSでやる最大のメリットかなと思います。

もちろんAWSには弱点もあります。残念ながらサポートが弱い。トラブルの解決は自分でやるしかない、ということです。なので、手間がかかることがあります。つまり、AWSはユーザーさんが直接システム構築をする環境ではないと。自分でやるから、と言うときっと後悔します。

例えば、バグでシステムが動きませんと。AWSのサポートに対応依頼のチケットを出すとします。そして解消したとしても、どこを直したかは「守秘に触れるので開示しません」といったことがあります。これがAWSです。

こうした対応が飲めないユーザーは使っちゃいけません。そして、たいていの日本のお客様はこれは飲めません。日本の感覚では、お金を払っているのだからこういう対応はないだろう、となります。

でもよく言われるのは、AWSのサポートはサービスサポートではなくプロダクトサポートだと。そう考えるとたしかにリーズナブルです。例えばOracleやSybaseでは、動かないときにはログとか細かいことはまずこちらで調べますよね。それと同じだと思ってください。

AWSのサービス全体が落ちることは基本的に考えられませんが、データセンター単位のトラブルが発生することがないとはいえないので、最初からマルチデータセンターで障害対策を考える必要があります。これはディザスタリカバリのあり方も変えていくと思います。

コストとパフォーマンスの技術的優位ははっきりしている

今回のプロジェクトでのクラウドの位置づけですが、やる必然性はあったのか。やっぱりあったと思います。

まず、コストとパフォーマンスの技術的優位は非常にはっきりしています。そして、ガバナンス。ドライな関係でのガバナンスが獲得できたこと。

可用性は通常のDCより高いと思います。マルチデータセンター、マルチアベイラビリティゾーンがデフォルトでできるようになっていますし、普通のデータセンターよりAWSの方が可用性が高い。

拡張性は非常に高いです。特に、本番環境をほぼ無数に作れます。これは楽です。簡単に同じ環境をがんがん作って拡大したり保全するのが簡単にできます。そういう意味で、いままでステージング環境と本番環境という枠組みがありましたが、AWSでは全然違う枠組みができます。おすすめです。

前例がない、という言い訳はできなくなった

西鉄プロジェクトは、結果としてミッションクリティカルをクラウドにあげる先行事例になりました。

もう「前例がない」という言い訳はできなくなったと思います。ミッションクリティカルも十分動きます。できちゃった、という実績は重いと思います。

最初からクラウドにあげる予定ではありませんでしたし、私は最後まであがるとは思っていませんでした。この仕組みは本来オンプレミスでやる仕組みですし、昔なら汎用機です。オープンでも躊躇します。それがクラウドにあがってしまった現実に、私がいちばんびっくりしています。

われわれが一生懸命AWSを売り込みたくてやったというのではなくて、これしか道がなかったのが現実です。そう簡単なものではないですし、コストを下げる目的でやるのは私は全然おすすめしません。

たしかに安くはなりますが、それは副次的なもので、クラウドに移行するメリットを把握してやるべきです。それは拡張性とか可用性とかで、最後がコストです。そういう目線でこの西鉄さんの案件を見ていただけるとうれしいですし、そういうスタンスでやったのがわれわれです。