大規模Webサービスの運用・保守について

質問

いつも拝見させていただいております。

今回は、ネットワーク周りの技術について質問させてください。
大規模なWebサービスを展開するにあたってWebサーバ・APサーバ等が
複数台におよぶケースがあると思います。
そこで各APサーバに修正したアプリを一括配布をしたいと考えています。
上記のようなケースでWebサービスを停止せずに裏でアプリの配布を進めたいです。
こういった運用方法はすでに事例があると思うのですが、一般的な方法を調べたいと
思っています。
そのような情報が世に出回っているのかわかりませんが、配布技術またはこのような
ツールを使用して実施している等、参考になる書籍等があれば教えていただけないでしょうか？

分野的にどこにあてはまるのかイマイチわからないので、本屋さんを漠然と探しましたが
めぼしいものが見つかりませんでした。

回答No.1

t4t · ベストアンサー

アプリケーションサーバ製品にはデプロイ機能がありますから、配布そのものは可能なのですが、いかに効率よく自動で大規模なホットデプロイをするかということですよね。
かなり専門的な話になるので、まとまった書籍としてはいいのがないかもしれません。
保守・デプロイ（配布）の戦略によっても方法論が異なりますし、アプリケーションサーバの種類によっても異なります。
最新のアプリケーションサーバ製品は複数サーバ構成を普通にサポートしていますから、デプロイや保守をサポートする機能も充実してきています。

たいていは、製品を買ってそのまま使うというよりは、システム構築の一環として、ソリューション的な（この製品をこう使えば御社の運用に適用できます、的な）提案や検討されると思います。
サーバのコンソールだけでは有効な一括配布ができない場合でも、内部でサポートされている機能を組み合わせて配布のためのサブシステムを作成することによって適用できるケースもあると思います。
アプリケーションサーバの製品資料だけならおそらく無料でしょうから、請求してみてはいかがでしょうか。

そういったアプリケーションサーバの製品機能とサーバ規模、運用者のスキル、そしてデプロイ戦略をふまえて、どういう保守系の設計にするかを決めていきます。
数台規模、デプロイ戦略は単純、運用部門がITに強い場合は、アプリケーションサーバのコンソールだけでできた(やってしまった)こともありますし、
十台規模、デプロイ戦略は多少複雑、運用部門はITに強い場合に、コンソールにプラグインを使って、裏でスクリプトを生成して自動配信するような設計にしたこともあります。
数十台規模、百台規模でデプロイ戦略がかなり複雑で運用部門がITにそれほど強くない場合は、デプロイ系列の専用サブシステムを別途開発したこともあります。

そういう意味では、大規模なシステムだと、「一般的な方法」というのはないかもしれません。
ケースバイケースでいろいろ違いがあるからです。運用担当者のスキルにも依存します。

こうしたい、というある程度明確なニーズはあると思いますので、
各サーバ製品がサポートする機能を俯瞰して、ニーズとのマッチを考えてみてはいかがでしょうか。

お礼

ご回答ありがとうございます。

やはり、ケースバイケースということなんですね＾＾
現在、知識を得たいと考えておりますのは数千台規模でのデプロイ戦略になります。
私自身、開発技術者なので運用関連の知識とネットワーク関連の知識に乏しいです。

デプロイ系列の専用サブシステムを別途開発するとしたらどのような言語を選択して
作成上の注意点がどこにあるのか等、ご教授いただくことは可能でしょうか？
あつかましい質問で申し訳ありませんが、可能な範囲でご回答いただけたら幸いです。

回答No.3

t4t

NDAに抵触したり実システムが特定できる可能性があるので詳しいノウハウをお伝えすることはできません。すみません。

私が構築した際は、UIはJavaとJSPで組みました。
私も数千台規模は未経験で、数百台規模程度での経験です。
アプリケーションサーバはJ2EE(製品名はご容赦ください）で、サーバはUnix系のOSで、デプロイそのものはシェルスクリプトを自動生成させるケースと、直接JavaでAPサーバのデプロイ機能を叩くケースがありました。
内容によってはサービスの再起動も必要でしたが、まあ手段そのものは愚直な配布の繰り返しです。（ホットデプロイも含め、APサーバの機能を叩くのはそんなに難しいことではありません）
ファイルの転送そのものは#2さんがご紹介くださっているようなマルチキャストを用いて同時コピーするような手段がとても有効です。

保守としてのデプロイ戦略もかなり難儀ですが、どのサーバにどの機能(サービス)をどういう組み合わせで配置すべきか、というアーキテクチャ的な戦略のほうがより大変でした。
性能やデータ整合性、トランザクションの粒度や厳密性の調整、機能ごとのスケーラビリティやアベイラビリティの考慮その他があり、保守は非機能要件の一つでしかなかったからです。（もちろん保守は非常に重要な要件です）

サービスの粒度や組み合わせ、デプロイの単位となるモジュールの粒度を工夫しました。（バージョンを含んだ各サービスの依存状況を整理するなど、操作用のUIもかなり苦心しました）
デプロイの途中で、あるサーバにはデプロイが済んでいて、別のサーバはまだ前バージョンが動いているといった場合に、それでも全体としては連携がとれてユーザに使えるようにしなければなりません。（どうしても多少のズレはあるので）
アプローチはいくつかありますが、現在デプロイ中のサービスだけ、全ユーザで使えない状態にしておいて、すべてのサーバにデプロイを済ませてからそのサービスをすべてのサーバで実行可能にするというのが最も単純な部類でしょう。
あるいは、できるだけ新しいサービスがデプロイされたサーバに負荷が許す範囲でユーザを関連付ける設計を行い、それ以外は古いサービスに接続させて、次々に新サービス側に切り替えていくというやりかたもあります。
こちらは、デプロイそのものよりも、整合性をあわせるように作り込んだり、自然に整合性が合うようにフレームワークを用意して作りこませるような工夫が必要になります。

当然内部ベータテストなどのためのステージングサイトも必要になるので、そちらにも対応しています。開発サイトから運用サイトには直接デプロイできないように設計していました。

回答No.2

t-okura

DSAS 開発者の部屋でファイル転送システムが公開されています。
http://dsas.blog.klab.org/archives/51342234.html
マルチキャストで配信するので、転送時間がサーバ台数に依存しないと
なっていますが、数千台規模で利用できるのかどうかはわかりません。

すごい規模ですね。