ソフトバンクモバイル（ＳＢＭ）は、ナンバーポータビリティ制の導入に伴って、事務処理量の増加に耐え切れずシステムダウンを起こしました。
一部では、話題を引くためにわざと障害を起こしたのではないかと言われたりもしましたが、その後も、システムダウンを起こし、致命的ともいえる出遅れになったところを見ると、予想外のシステムダウンだったようです。
では、システムダウンを起こした事務量というのを考えてみましょう。
ＳＢＭでは、毎月、顧客ごとに回線使用料を集計して、プランごとの複雑な割引を行い、請求書を発行し、銀行からのデータと照合して、入金消込み処理を行っています。
ナンバーポータビリティ制の導入で各ショップに顧客が殺到といっても、全顧客の１％に満たない人数だったそうで、毎月の請求処理の複雑さ処理量と比べると、システムの処理量がオーバーするほどのものでないことは明らかです。
つまり、処理量が、根本的なサーバーマシンの限界値をオーバーしたとは考えにくいです。
では、なぜ、システムダウンを起こしたのでしょう。
私はマシンスペックは十分だったけれど、システムの構造上、無駄な処理が含まれていたためではないかと思います。
ＳＢＭの業務形態を考えるとショップ毎にシステム管理者を置けないため、システムの構成はＷＥＢシステムで、おそらく、データをＲＤＢＭＳに保存して、ＪａｖａやＡＳＰ.ＮＥＴなどを使ったではないかと思います。
私は部外者なのでまったくの憶測ですが、この構成だったとして話を進めます。
今回の予想外の割引処理やナンバーポータビリティ制に対応する処理は、ＲＤＢＭＳサーバ（データベースサーバ）でも、ＡＰサーバ（プログラム実行サーバ）のいずれでも処理が可能です。
そのため、どちらで処理を行うかは設計者の好みで変わります。
私の予想は、システム障害が起きた原因は『ＡＰサーバで処理していた』からではないかと思います。
ＷＥＢシステムでは、処理概要は次のようになります。
各ショップのクライアント
↓↑
ＡＰサーバ
↓↑
ミドルウェア
↓↑
ＲＤＢＭＳサーバ
これらを少し分かり安く、文房具の出荷工場と、文房具店という構造で説明します。
各ショップのクライアント ＝ 文房具店
ＡＰサーバ ＝ 商社
ミドルウェア ＝ 営業マン
ＲＤＢＭＳサーバ ＝ 出荷工場
となります。
文房具店では、新入学の季節を迎えたので、鉛筆１ダースと消しゴム、筆箱、をセットにしてラッピングして１０００セット販売することになり、営業を呼びました。
このときのＡＰサーバ（商社）とミドルウェア（商社の営業マン）の作業を考えると次のようになります。
★ ＡＰサーバで処理した場合。
以下の手順で注文します。
文房具店から１０００セットのオーダーを受ける。
以下を１０００回繰返し
鉛筆の箱の注文（ＳＱＬを書く） → 営業マンが出荷工場へ → 商社へ
鉛筆を１本の注文（ＳＱＬを書く） × １２回 → 営業マンが出荷工場へ → 商社へ
商社で箱に詰め込む
消しゴムの注文（ＳＱＬを書く） → 営業マンが出荷工場へ → 商社へ
商社でラッピング作業（HTMLの生成）
（繰り返し終わり）
文房具店へ１０００セットを届ける。
結局、出荷工場は１５０００回出荷処理を行うことになり、営業マンは１５０００回、商社と出荷工場を往復します。
★ ＲＤＢＭＳサーバで処理した場合。
文房具店から１０００セットのオーダーを受ける。
商社で、鉛筆１ダースと消しゴム、筆箱を１まとめにしたものを
１０００セット分の注文書を書く。
→ 営業マンが出荷工場へ → 出荷工場から商社へ
商社でラッピング作業
文房具店へ１０００セットを届ける。
どこに問題があるか、小学生でもすぐに判りますね。
コンピュータは動作が速いので、１つの文房具店から鉛筆１本づつ、１０００セットの注文が入っても一瞬で返してくれます。
ですから、この問題は開発期間中に気づくには、それなりの経験が必要です。
（ハードで解決していたら、何回でも失敗するんですが…）
しかし、ＡＰサーバで処理すると、営業マンが何度も往復し、ラッピング処理をするまで鉛筆や消しゴムを置く場所をＡＰサーバ内にキープしています。
そのため、注文してくる文房具店が増えると、営業マンが足りなくなるか、作業場所がなくなるか、出荷工場の出入り口の渋滞（ネットワーク障害）などのいずれかの問題が発生します。
営業マン・作業場所が足りないのであれば、商社を増やせばよいでしょう。
商社を増やす、つまり、ＡＰサーバの増設はプログラムをコピーしてつなげれば増やせます。
（分散するためのルータは必要です）
しかし、ＲＤＢＭＳサーバは単純にコピーすればよいというわけにはいきませんから、ＲＤＢＭＳサーバで処理していて、ＲＤＢＭＳサーバの処理量を超えてシステムダウンしたときの増強は簡単ではありません。
ＳＢＭでは半日で「増強しましたもう大丈夫です」と発表して、その数時間後に再び止まるようなことになりましたが、ＲＤＢＭＳサーバで処理していては起きない症状で、ＡＰサーバで処理量がオーバーしたときに起きることです。
ですから、私の想像はおそらく当たっています。
ＤＢサーバの処理量がオーバーしたなら、１週間程度は止まっていたでしょう。
ＤＢサーバは増強しにくいから、増強しやすいＡＰサーバで処理した方が安全でしょうか？
そう主張される技術者も多いです。
しかし、あなたが出荷工場の担当者（ＲＤＢＭＳサーバ）になったつもりで『よ～く考えよう～♪』ＡＰサーバで処理（鉛筆１本ずつの注文）と、ＲＤＢＭＳサーバで処理（セットで注文）どちらがうれしいでしょうか？
『増強しやすいＡＰサーバで処理した方が安全』と主張するなら、ＲＤＢＭＳサーバの処理をＡＰサーバが肩代わりしている必要がありますが、ＡＰサーバーで処理した場合、ＲＤＢＭＳサーバの処理はむしろ増えているのです。
多分、ＳＢＭは大量にＡＰサーバを追加することで乗り切ったでしょう。
それで解決できるならよいとも言えますが、ＡＰサーバの増強で乗り切れるなら、ＲＤＢＭＳサーバで最初から処理していれば、そもそもシステムは止まらなかったのです。
１日に１％に満たない顧客が来店しただけで処理が溢れるなら、毎月の請求書に３ヶ月掛かる計算になりますね。（こんな単純な計算が出来ないＳＥ＆ＰＧがなんと多いことか…）
ＡＰサーバ中心で処理させるというのは一般的な構造で、大きな問題が起きなかったＡＵやＤＯＣＯＭＯなどは、最初から、それはもうびっくりするぐらい大量のサーバをつないで処理していたのかも知れません。
プログラミングとは、要望・仕様という自然言語（日本語）を人造言語（プログラミング言語）に翻訳する作業なのです。
それを、英語で言えば関係代名詞などを使った文章は難しいので、現在形のみの単文で書きましょう、という方向性は普通に考えればプロとしてあり得ない話だと分かるでしょう。
しかし、ＡＰサーバで処理する方がわかりやすいシステムになりやすいため、現在のソフトウェア業界では、複雑なＳＱＬは出来るだけ使わない方向へ動いています。
けれども、技術者が足りないから、英語の翻訳で言えば関係代名詞を使えないレベルのプログラマ、ＳＥを促成栽培して技術者として仕事をさせてしまう。
促成栽培方法と、そのレベルでもシステムが作れる方式というのを、業界として確立したわけです。
それは、ある意味すばらしい技術ではあるのですが、ＳＢＭの障害ような潜在的な問題を抱えてしまう。
経営者としては、苦労せずに稼げる促成栽培に移行すれば一番儲かる（笑）
そちらへシフトさせるか非常に悩むところではあるのですが、結局、私は業界で確立された方式に異を唱えてがんばっているわけです。
「SQLについて（安い、且つ 速いシステムを作るには)」 の問題が１０分で出来る技術者で構成したプロジェクトなら、もっと儲かるはず！という絵に描いた餅を実現するために。
コラムの全インデックス
記事一覧 (42)
