ウェブサイト及びサーバー監視の プレミアム製品

Server Densityについて

ゼロダウンタイムの新しい環境へ高スループットのアプリケーション移行

現在、当社はすべてのサーバーとウェブ監視関連の製品であるServer DensityをSoftlayer からGoogle Compute Engineへと移行するプロジェクトを終えようとしています。当社ではサービスを提供するために100台以上のサーバーが稼働中であり、毎月 30-40TB 程度のデータを処理し、毎日MongoDB へ10億ものドキュメントを書き込んでいます。Server Density はお客様の42,000台以上のサーバー監視のために負担がかかっておりますが、ゼロダウンタイムで影響を最小限に抑えるために気をつけなければなりません。

このポストではどのように移行を計画し、遂行するかについて論じます。

Server Densityのインフラ環境

なぜGoogle Cloudへ移行するのか?

ここ数ヶ月間、私はUKやUSにて移行のプロセスに関して話をしてきましたし、このポストの一番下のビデオでさらに詳細の理由について説明しています。また近いうちになぜGoogle Cloudに移行したか書きたいと思います。 何か質問があれば、是非コメントを書き込んで下さい!

移行へのステップ

ゼロダウンタイムで影響を最小限に抑える必要があり、移行のプロセスは複雑であるためにこのプロジェクトに関していくつかのステップを踏みました。

  1. 計画
  2. テスト
  3. 複製
  4. 切換え

すべてのプロジェクトの中でもっとも大切なポイントはできるだけシンプルにするということです。 – 当社はSoftlayerでサーバーが稼働しており、Google Compute Engineのサーバーへ 1:1 で移行することを計画しました。これは初期の段階でロードバランサー、バックアップ用のスナップショットなどのGoogle Cloud のたくさんの機能を使用しないことを意味します。私共は将来的にはこのような機能は使用する予定ですが、変更点をできるだけ少なくして、できるだけ既存の環境のまま移行させることにしました。

Screen-Shot-2014-08-26-at-12.03.42

ステップ1: 計画

100台以上のサーバーと多大な トラフィックを移行するためには多くの作業が伴い、最新の注意を払って計画をせねばなりません。以下の様な質問への問いかけが必要です。:

  • 違いは何か? – 新しい環境は古いものとは違います。多分違ったOSのイメージが利用可能でしょう。またネットワークも違った形で設定されているかもしれません。地域やゾーンはどのように設定しましょうか?多くの人が Amazon zones は独立していると思っていますが、すべての地域で失敗がおきるかもしれません。Google は特にゾーン間で展開すれば冗長性のために十分であると言っています。しかしながら、決して100%の保証はありません!
  • ベンダー特定のAPIがあるか? – 新しい環境にはないかもしくは全く同じAPIもしくは特定のベンダーの機能を使用しているかもしれません。再実装のためにはスクリプトが必要になるかもしれません。
  • 新たに修得することは?- 上記の質問に関連しますが、これはいかに新しい環境が稼働しチームが通常の業務を行うことができるように知識を身につけなければなりません。フェイルオーバー、サポートのプロセスやリソースなどについてです。
  • コスト – 既存の環境を複製して、しばらくの間は同時に2つの環境を稼働させるので、コストは2倍はかかります。このためできるだけ複製する部分を削減できるようにうまく計画を策定しなければなりません。新たしい環境のコストはできるだけ既存の環境と比較して十分にモデルを作るひつようがあります。そうすることにより、全く予想していなかったi/oやネットワークのコストを心配する必要がなくなります。

ステップ 2: テスト

この段階は全く違った環境で、現実的にプロダクションのワークロードのシミュレーションが必要になるので、一番時間がかかります。Softlayer では当社はMongoDBの配備のためにSSD搭載のカスタムスペックの専用サバーを保有しておりGoogle Compute Engineでも少なくとも同等レベルのパフォーマンスを確保したいと思っています。

私はここで重要な情報を発見しました。例えば Google Compute Engineのインスタンスはディスクをどのように正確に設定するかまたはRAIDが不必要であるなど、ディスクボリュームとVMの両方を制限するということです。

また最新のLinuxのカーネルを使用していることを確かめることが重要です。少なくともLinux 3.3 を使用することによりGoogle SSDsの最良のディスクパフォーマンスが可能になります。また最近では私は新しいGoogleディスク製品をテストしており、これによりMongoDBより優れたパフォーマンスが可能になります。近いうちにこのサービスについては発表することができるでしょう!

GCEでの共通する問題はボリュームサイズが小さすぎるということです。これは IOPのボリュームのザイズに応じて直線的に調整されるためです。 そして、ディスクの必要なスペースに応じて設定すると、ディスクの設定が小さくなってしまいます。

Google Computeエンジンの共通の問題

ステップ 3: 複製

さて、ここで本当の意味の移行が始まり、新しいプロバイダーの環境への複製が行われます。. ここでは主に Puppetを使用しました。 なぜならば、すべの設定が一元化できるので、自社のすべての環境を定義し、他でサーバーを複製することが簡単です。

MongoDBは使い易い複製の機能を持っており、データを複製するためには新しい環境へ複製のスレーブを簡単に設定するだけです。Benchmarking the connectivity between Softlayerと GoogleのUS地域の接続性のベンチマークでは、当社は 250Mbps以上のスループットがあります。これはSoftlayer’s WDCと 冗長性のために複製するSJCデータセンターの間の数値とほぼ同じです。

MongoDBで複製をせっていするには、複製のセットとクライアントのすべてのコネクションをSSLかVPNを設定して使用することが必要です。SSLはカスタムメードのバージョン(もしくはエンタープライズバージョン)のMongoDBでのみ使用が可能です。 MongoDB 2.4はローリングのアップデートができず、すべてのクラスターがSSLを使うか全くなしでやることになるので、あまり優れものではありません。 MongoDB 2.6ではこの問題は解決されていますが、当社では現在バージョン2.4で稼働させており、原則として新しい主要なMongoDB のバージョンへはアップグレードしません。

これはVPNの設定が必要になり、SoftlayerとGoogleの両方のVPNのサポートを使用することで可能になります。

接続性 - VPN かSSL?

ステップ 4: 切換え

当社はGoogle Compute Engineに環境に複製しており、これは効率的な第二のデータセンターであるので、プライマリーのデータセンターからのフェイルオーバーのように切り替えることができることができます。

このプロセスを行うためには Softlayer MongoDB のノードをフリーズさせる必要があります。 それにより、プライマリー変更せずにステップダウンをすることになり、 Googleノードがプライマリーにしてから、まずはトラフィックがGoogleに行くようにしてDNSを切換えます。ユーザーによっては古い施設のウェブサーバーにアクセスしたり、データがVPN経由で他のプロバイダーへ送信される場合には遅れも発生します。しかしながら、これはすべて透明で重要であり、ダウンタイムがあってはなりません。

明らかにこれはどのように機能するかの簡単な説明です。実際には、当社はいつどのようなステップをとるかについての細かな確認リストを持っています。事前にリハーサルをすることは重要であり、当社が切換えの日に何も見逃すことないように確認することができます。

切換えが終わったら、すべての機能が稼働しているか確認してから、古い環境を止める作業を始めることができます。これはまずサーバーを止めて、数日後にSoftlayerとキャンセルをします。これによりサーバーを実際に壊さずに何か見逃したことはないか見つけることができます!

切換え

現状

当社はGoogleでの新しい環境を準備する最終段階です。移行が終了したらフォロアップの投稿を期待していて下さい。どのように移行が進んで、どんなことを学んで、どのように問題を解決したかをご説明したいと思います。もし読者の方がお客様であるならば、新しいIP(もしホワイトリストに登録されているのであれば)と共に移行の日をステータスのページで公表します。