お問い合わせ

03-5677-3930初診受付

ブログ

2015年7月8日

6750 ピンチに陥らないシステムダウンの起こし方:

局所化、ダウンタイム最小化、連絡体制――現場の技 
記者の眼 日経SYSTEMS
ピンチに陥らないシステムダウンの起こし方 2015/06/26
白井 良=日経SYSTEMS

「絶対にシステムダウンを起こさない前提」でビジネスを設計すると、システムダウン時にビジネスがピンチに陥る。システムダウンへの備えが必要。システムを完全無欠にするにはコストが掛かり過ぎる。現実路線はシステムダウンが起こることは受け入れ、「ビジネスに致命傷を与えないようにシステムダウンを起こす」というもの。

 プラグラムは2015年5月末には導入店数が8000店舗超。同社が実践している取り組みのうち、「障害の局所化」「ダウンタイムの最小化」「連絡体制の整備」の三つを紹介する。

〇障害の局所化とは、ユーザーを小さなグループに分け、障害を全体に波及させないシステムにした。

〇ダウンタイムの最小化とは、具体的には「予備のサーバーをあらかじめ複数作成しておき、障害発生時は1秒でも早く丸ごと入れ替える」。異常が発生したサーバーにSSH(セキュアシェル)接続し、原因を探って、再起動などの対応作業をする――といった手順はすべて飛ばす。 予備機となるサーバーを作成して「STOP」(電源オフ)しておく。

〇連絡体制の整備は、コールセンターによる電話サポートを用意するといったもの。

 システムを止めないのではなく、障害を全体に波及させないことを考える。システムダウンしても1秒でも早く復旧できる方法を用意しておく。ユーザーの利用実態に即した連絡方法を用意しておく――。そのまま使えるものではないかもしれないが、参考にすべきアプローチ。

  ーー本文引用ーーーー
http://itpro.nikkeibp.co.jp/atcl/watcher/14/334361/062100301/?ST=system&P=1

 システムダウンは避けられない。バグや操作ミスを完全にゼロにすることはできないし、想定外のことはいつだって起こる。「絶対にシステムダウンを起こさない前提」でビジネスを設計すると、システムダウン時にビジネスがピンチに陥る。ビジネスへの影響を最小限にする、システムダウンへの備えが必要なのだ。

 従来、止まってはいけないシステムは「ミッションクリティカル」とされた。可用性を高める多大なシステム投資をし、監視漏れとミスを防ぐために大人数で運用する。ところが、今ではあらゆるビジネスでシステムの利用が前提になっている。より「軽い」システムも止まっては困るのだ。クラウド、モバイルの流れで、ベンチャー企業が小さく始めたサービスが数年で重要システムに化けたりもしている。

 ところが、あらゆるシステムを既存のミッションクリティカルシステムのように作るのは不可能だ。コストが掛かり過ぎるからである。ミッションクリティカルシステムの構築経験が豊富な日本ユニシスの高井健志氏(公共システム本部 第一統括部長)は「数百億円規模の投資ができる企業でないと、稼働率99.995%のような『絶対に止めてはならないシステム』を作るのは難しい」と言う。

 ミッションクリティカルシステムを作るには、すべてのハードウエアを何重にも冗長化する必要があるし、待機系に素早く切り替わるようアプリケーションとインフラをチューニングしなければならない。「稼働率99.9%まではたいした工夫がいらないが、それより上げるには大変な手間が掛かる」(日本ユニシスの高井氏)。

 ここまでの投資が可能なシステムは、ほとんどないだろう。現実路線はシステムダウンが起こることは受け入れ、「ビジネスに致命傷を与えないようにシステムダウンを起こす」というものだ。

局所化、ダウンタイム最小化、連絡体制――現場の技…

 ではどうすれば良いのか。iPad/iPhone向けPOSレジアプリ「スマレジ」を運営するプラグラムの取り組みから、具体例を見ていこう(写真1)。

 プラグラムは急成長するサービス事業者として、システムダウンと悪戦苦闘を続けてきた。2011年にユーザーが1店舗もない状態から始め、2015年5月末には導入店数が8000店舗を超えた。同社代表取締役社長の山本博士氏は「ユーザーにとってシステムダウンは一番のストレスになる。試行錯誤しながらストレスを少なくする方法を探ってきた」と言う。

 同社が実践している取り組みのうち、「障害の局所化」「ダウンタイムの最小化」「連絡体制の整備」の三つを紹介しよう。

 一つ目の障害の局所化とは、ユーザーを小さなグループに分け、障害を全体に波及させないシステムにしたことだ。2013年10月22日に発生したシステムダウンがきっかけになった。「一つの店舗が一気に大量の注文を処理しようとした結果、システム全体でデータベースの応答がスローダウンした」(山本氏)。

 それまではユーザー数の増加に応じて、データベースサーバーをスペックアップして対応する方針だった。しかし、想定外が発生するという現実に直面して方針を変更した。システムを改修して、ユーザーをグループ化してデータベースを小さく分ける構成にした。単一グループでシステムがスローダウンする恐れはあっても、ほかのグループには影響を及ぼさない。

二つ目のダウンタイムの最小化とは、システムダウン…

二つ目のダウンタイムの最小化とは、システムダウン時の復旧作業をシンプルにしたことだ。具体的には「予備のサーバーをあらかじめ複数作成しておき、障害発生時は1秒でも早く丸ごと入れ替える」(山本氏)といったものだ。一般的な障害対応である、異常が発生したサーバーにSSH(セキュアシェル)接続し、原因を探って、再起動などの対応作業をする――といった手順はすべて飛ばす。

 こうした復旧策が取れるのは、同社がパブリッククラウドを基盤に使っているからだ。システムはAmazon Web Servicesの仮想マシン「EC2」を中心に構成している。予備機となるサーバーを作成して「STOP」(電源オフ)しておく。占有するストレージ分の料金は掛かるが、EC2の料金は掛からない。

 特に有効なのは容量不足でダウンした場合だ。「AWSはスケールアウトは素早くできるが、スケールアップには時間が掛かる」(山本氏)。サーバーの性能を上げるには、サーバーをいったん止めて作り直さなければならないからだ。そこで、性能が高い予備サーバーを作って、待機させておく。

 三つ目の連絡体制の整備は、コールセンターによる電話サポートを用意するといったものだ。飲食店や小売店は営業時間中にパソコンを見る機会が少ない。Webサイトで「お知らせ」を出しても見てもらえないのだ。メールによる配信は、システムダウンの通知に使うにはタイムラグが大きすぎる。山本氏は「どうしても電話対応が必要になる。初期にはそこまで考えが及ばず、ユーザーから叱られた経験もあり、今の体制に落ち着いた」と言う。

 システムを止めないのではなく、障害を全体に波及させないことを考える。システムダウンしても1秒でも早く復旧できる方法を用意しておく。ユーザーの利用実態に即した連絡方法を用意しておく――。プラグラムの取り組みは示唆に富む。現場によって使っているITインフラやユーザーの特性が異なる。そのまま使えるものではないかもしれないが、参考にすべきアプローチだ。

Categorised in: 未分類