基幹システムをクラウドへあげるのは簡単ではなかった。PublickeyTopクラウド基幹システムをクラウドへあげるのは簡単ではなかった。基幹システムをクラウドで実現する。その過程でどのような技術を用い、どのような苦労があったのか。Services)の上で実現したノーチラス・テクノロジーズが、その詳細について紹介したセミナーを5月15日、アマゾンジャパン本社のセミナールームで開催しました。(本記事は「基幹システムをクラウドへあげるのは簡単ではなかった。ノーチラス・テクノロジーズがクラウドの現実を語る(前編)」の続きです)和製クラウドでトラブルが続き、やむなくAWSへ移行インフラについて。和製クラウドベンダのインフラは値段が高い。話をして安くならないかと相談したけれど、無理でした。データセンターは人を雇っていて、彼らを食わせなければならないので安くならない。それから自分たちで対応できないんですね。仮想化とかソフトを入れるとできてしまうので、自分でデータセンターを作ってないんです。トラブルになると「ベンダに聞いてみます」とか。最後はわれわれがトラブルシュートして、「このバグにはこのパッチを当ててくれ」と言うと「怖くて当てられない」とか、よく分からない返事が返ってきます。和製クラウドも、AWSと競争するために機能は必要。すると、とりあえずソフトウェアを入れて「AWSと同じことができます」と、こうなるわけです。「Hadoopもできます」って言う。ところがHadoopのクラスタを動かしてみると障害が頻発です。パフォーマンスもすごく遅くなりまして、サーバが落ちてバッチが止まりましたと。Hadoopでバッチが止まるのは相当なことです。Hadoopは分散環境ですから、ノードが1つ2つ落ちたくらいでは止まりません。このときは3分の2以上のノードが一気に止まるという考えられないことになって。原因究明もこちらで行うことになりました。全面カットオーバーの前にこれが起きて、極めて不安だと。ユーザーさんと話をして、そこでAWSへ移行することになりました。時間はあと1カ月しかありませんでしたが。私たちは、アンデルセンさんの案件で基幹を経験してやり方は分かっていたので、ギリギリできるかなと。だめだ、というところまで何度もいったAWSへの移行はうちのエンジニア1人で対応しました。彼はうちのエースで、彼に変わる人材はノーチラスにはいませんし、私は彼ほど優秀なインフラエンジニアに会ったことはありません。線表を一緒に引いて、3日単位でマイルストーンを決めて、クリアできなければ残念ながら元の環境でやると、お客さんにもそういう話をしながら、3日単位で判断しつつ、いつでも戻せるようにしてやりました。だめだ、というところまで何度もいきました。プレスリリースで書いたような、簡単なものではありませんでした。AWSに移行したのは適切だったのか。結論から言えば適切だったと思います。使い方を間違えなければコストパフォーマンスは通常の倍はでます。可用性もやはり高いです。一回あげると落ちません。この2つの技術は抜群で、これに代わる技術はほかのクラウドベンダにはありません。AWSを使って本気でSIをやる、あるいは基幹を運用するのであれば、EC2とS3を徹底的にマスターするべきだと思います。そのうちほとんどのノウハウはS3に近いところにあるのではないでしょうか。AWS最大のメリットはガバナンス。弱点はサポートAWSのメリットはコストではありません。たしかにコストは魅力的ではありましたが、いちばん大きいのはガバナンスです。AWSはいい意味でドライです。われわれがやることに、ああしろこうしろということはありません。既存のSIerのデータセンターでは、必ず政治的になります。そちらのためにこれを準備したとか、それならサーバ買ってくださいとか、値引きするからこうしてくださいとか。いったことなく、自分のガバナンスを確保できる。これがAWSでやる最大のメリットかなと思います。AWSには弱点もあります。残念ながらサポートが弱い。トラブルの解決は自分でやるしかない、ということです。手間がかかることがあります。AWSはユーザーさんが直接システム構築をする環境ではないと。自分でやるから、と言うときっと後悔します。バグでシステムが動きませんと。AWSのサポートに対応依頼のチケットを出すとします。解消したとしても、どこを直したかは「守秘に触れるので開示しません」といったことがあります。した対応が飲めないユーザーは使っちゃいけません。日本のお客様はこれは飲めません。日本の感覚では、お金を払っているのだからこういう対応はないだろう、となります。言われるのは、AWSのサポートはサービスサポートではなくプロダクトサポートだと。考えるとたしかにリーズナブルです。OracleやSybaseでは、動かないときにはログとか細かいことはまずこちらで調べますよね。それと同じだと思ってください。AWSのサービス全体が落ちることは基本的に考えられませんが、データセンター単位のトラブルが発生することがないとはいえないので、最初からマルチデータセンターで障害対策を考える必要があります。これはディザスタリカバリのあり方も変えていくと思います。コストとパフォーマンスの技術的優位ははっきりしている今回のプロジェクトでのクラウドの位置づけですが、やる必然性はあったのか。コストとパフォーマンスの技術的優位は非常にはっきりしています。ドライな関係でのガバナンスが獲得できたこと。可用性は通常のDCより高いと思います。マルチデータセンター、マルチアベイラビリティゾーンがデフォルトでできるようになっていますし、普通のデータセンターよりAWSの方が可用性が高い。拡張性は非常に高いです。本番環境をほぼ無数に作れます。簡単に同じ環境をがんがん作って拡大したり保全するのが簡単にできます。いう意味で、いままでステージング環境と本番環境という枠組みがありましたが、AWSでは全然違う枠組みができます。前例がない、という言い訳はできなくなった西鉄プロジェクトは、結果としてミッションクリティカルをクラウドにあげる先行事例になりました。「前例がない」という言い訳はできなくなったと思います。ミッションクリティカルも十分動きます。できちゃった、という実績は重いと思います。最初からクラウドにあげる予定ではありませんでしたし、私は最後まであがるとは思っていませんでした。この仕組みは本来オンプレミスでやる仕組みですし、昔なら汎用機です。オープンでも躊躇します。それがクラウドにあがってしまった現実に、私がいちばんびっくりしています。われわれが一生懸命AWSを売り込みたくてやったというのではなくて、これしか道がなかったのが現実です。簡単なものではないですし、コストを下げる目的でやるのは私は全然おすすめしません。たしかに安くはなりますが、それは副次的なもので、クラウドに移行するメリットを把握してやるべきです。それは拡張性とか可用性とかで、最後がコストです。いう目線でこの西鉄さんの案件を見ていただけるとうれしいですし、そういうスタンスでやったのがわれわれです。≫次の記事グローバルなクラウド市場でAmazonクラウドは突出したリーダー。基幹システムをクラウドへあげるのは簡単ではなかった。Niino(jniino)IT系の雑誌編集者、オンラインメディア発行人を経て独立。2009年にPublickeyを開始しました。2.7サポートを発表Google、Lookerの買収完了を発表。Enterprise、BtoBスタートアップ向け支援プログラムで無料提供と発表。usPublickeyについて/運営者についてお問い合わせ広告についてプライバシーポリシ。