トラブルが起こりやすい場所
前回詳しく見てきたように、2011年4月に仮想マシン貸しサービス「Amazon EC2」で発生した障害は、提供元の米アマゾン・ウェブ・サービシズ（AWS）にとって過去最大規模の障害だった（写真1）。しかし、こうした障害は珍しくはない。クラウドサービスでは、様々な大規模トラブルが発生している（表1）。 少なくないストレージのトラブル EC2での障害の原因は、EC2と組み合わせて使う同社のストレージサービス「Amazon EBS」にあった。アマゾン・ウェブ・サービシズや米グーグルは、ストレージの可用性を上げるために独自の分散ストレージを開発している。そのストレージが弱点になることがある。 例えばアマゾン・ウェブ・サービシズでは2008年に、EBSとは別のストレージサービス「Amazon S3」で、大規模な障害が2度発生している。S3は、AWSが独自に開発したピア・ツー・ピア（P2P）技術を採用
クラウド時代は運用が主役
「開発担当者も運用担当者もこれからは『運用』というキーワードが大事になる」。日経コンピュータ11月10日号の特集「創る『運用』」でクラウド時代におけるユーザー企業のシステム運用の姿を追ったところ、こう考えているユーザー企業の情報システム部門が増えてきたことを実感した。 運用が大事になる。そう言っても、ハードウエアが故障したときに修理できるとか、統合運用管理ツールの仕組みに詳しいとか、技術的なことではない。もっと大きく、「運用する」ことを起点にシステム開発やシステム運用を考えましょうということだ。 具体的には次のような流れになるだろう。情報システム部門はサービス提供の手段としてシステムを開発し、運用する。時には外部のクラウドを使う。利用部門にとっては提供元はどこでもよく、適切なシステムを利用できれば事足りる。情報システム部門は、クラウドサービスの利用や自社システムの運用を通じて、サービスの課
クラウドによるIT産業空洞化に対処できるのか
グローバル展開を強化しつつあるユーザー企業の話。最近は進出した現地に情報システムは置かず、すべて日本国内のデータセンターからプライベートクラウドの形で提供するという。日本のITベンダーからすると理想的パターンだ。なんせ従来なら外国で実施されたはずのIT投資まで日本国内に落ちる。これなら産業空洞化も怖くない。しかし残念ながら、このままでは済まないようだ。 実は、この企業の経営者は次の展開を考えている。数年以内にプライベートクラウドをアジアのどこかに移すことを検討しているのだ。そうすることによって、システムの運用コストが劇的に下がる。これまでは海外事業の急速な立ち上げを支援するために、システムを日本国内に置いていたが、それがひと段落すれば、なにも高コストの国内にシステムを運用することはないからだ。 この経営者がそのことに気付いたのは、クラウドの“お陰”という。以前なら海外拠点のシステムはそれぞ
［5］保証稼働率「99.9％」の意味
自社運用（オンプレミス）のメールシステムからクラウド型メールへ移行する場合、企業のシステム管理者であれば、「システムに問題が生じていないか」「障害が発生しているならどのように対処が進んでいるか」といった情報の提供体制を把握しておきたい。システム運用を外部に委ねるクラウドだけに、システム管理者が自らメールシステムの障害対応に当たることはないが、従業員からのクレームの対処などを考えると、システム稼働状況は常に分かるようにしておきたいものだ。 グーグルの「GoogleApps（Gmail機能を含む複合アプリケーション）」では、システム全体の稼働状況を「Status Dashboard」というWebページで、ほぼリアルタイムに公開している（写真1）。得られる情報は限られるが、不具合が生じた場合に、Google Apps側に障害が発生していることが原因なのか、自社側に問題があるのかを知る目安として使
［1］膨れ上がる運用負荷と決別
電話やFAXと並んで、企業ユーザーのコミュニケーション手段として欠かせない電子メール。そのシステム運用を外部に任せようという機運が高まっている。米グーグルの「Google Apps」（同サービスはGmailやスケジューラーなどで構成）をはじめとする、クラウド型メールを社内向けに使うのである。 クラウド型メールの魅力は、大容量のメールボックスを低料金で利用できることと、初期投資や運用負荷を軽くできることである。クラウド型メールは、自社運用（オンプレミス）に比べて、大勢のユーザーがコンピューティング資源を共有するため、コスト効率が高い。このため、「自社でメールサーバーを運用すること自体が、本業の競争力につながるわけではない」と考える企業の採用例が目立ってきた。代表的なアーリーアダプターとして、ユニ・チャームや東急ハンズ、ガリバーインターナショナルなどが挙げられる。 現時点でメールサーバーをオン
不可能を可能にするPaaS型サービス
最近、サービス提供事業者も導入企業も増えているPaaS（パース）型のクラウドコンピューティング・サービスでは、従来のSaaS（サース）型とは違って、自社の独自アプリケーションを動かすことができます。そのうえ、利用者数の急増に自動的に対処してくれる点なども好評で、導入企業の多くが「従来は不可能だったことが実現できる」と口をそろえます。今回（本連載の第2回）は、主なPaaS型サービスの特徴と、ユーザー企業がそれらを選んだ理由を紹介していきます。 PaaSに関しては、グーグルの「Google App Engine」、セールスフォース・ドットコムの「Force.com」と「Heroku（ヘロク）」、日本マイクロソフトが提供する「Windows Azure Platform」に加えて、米アマゾン・ウェブ・サービシズの「Amazon Web Services（AWS）」を取り上げる。 AWSのサービス
クラウドの運用性＆セキュリティ
パブリッククラウドを利用することで得られる大きなメリットの一つに、「運用負担の軽減」がある。サーバーやストレージといったハードウエアはサービス事業者の所有物で、それらの購入からセッティング、OSへのパッチ適用といったメンテナンスまで、サービス事業者の責任で実施する。サービスを利用する側の負担は軽減する。 だからといって、運用負担がなくなるわけではない。特に注意が必要なのがシステムの監視である（図1）。「従来の業務システムと同じレベルを確保するには、サービス事業者が提供する標準の監視機能だけでは不十分」（リクルート 戸建・流通・賃貸カンパニー 事業推進部 事業開発グループ 矢本俊之氏）という声が少なくなかった。この問題に直面して乗り切った、オリンパスメモリーワークスとリクルートの工夫を紹介する。 また、運用性と関連し、パブリッククラウドを利用する際の懸念事項に挙げられる「セキュリティ」につい
Googleの巨大分散データストアBigtableとDatastoreを理解する
今回は、米Googleのクラウド環境に存在するデータベースBigtableとDatastoreサービスを紹介します。「巨大分散」という新たなデータベースの地平を切り開くためにどのような工夫をしているか、じっくり見ていきましょう。 「Bigtable」は、Googleの主要なサービスを支える独自の巨大分散データストアです＊1。Bigtableは、2005年4月から本格的な運用（プロダクション利用）が開始されたもので、Googleの検索サービスをはじめ、Gmail、YouTube、Google Maps、Google日本語入力、そしてApp Engineなど、70以上のプロジェクトで利用されています。その規模は、数P（ペタ）バイト～数十Pバイトに達しているでしょう。 Bigtableは、Google検索サービスにおける膨大なコンテンツやインデックスを保持し、高速に検索するための専用データストア
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
