「送り状発行システムB2クラウド」障害を振り返る
先週、ヤマト運輸がビジネス顧客向けに自社インフラ基盤で提供している「送り状発行システムB2クラウド」が3日間ほどアクセスしにくくなる障害が起こっていました。
ヤマト運輸は9月27日、接続エラーのため利用できない不具合が24日午前から続いていたサービス「送り状発行システム B2クラウド」が復旧したと発表した。同社は原因について「アクセス集中など」と説明し、「システムの諸改修を実施したため、現在は通常通りご利用いただける」としている。
私が初めてヤマトの宅急便を使ったのは、高校になって実家から離れたときに荷物を段ボールにまとめて発送するときでした。専用の書類に住所や名前、電話番号を書くのは大変骨が折れる作業で、しかも送り先と送り元の住所を手書きしなければいけない。
それは1通ならまだいいんですが、昨今ECの伸長で通信販売を行う事業者も増えましたから、たくさんの発送を行う場合は手書きではやってられません。ということでパソコンから普通のプリンター経由で送り状を印刷できるというのがこのシステムの概要です。
原因を「アクセス障害など」とヤマトが明かしていますので、これは消費税が上がる前の駆け込み需要だったのは間違いありません。各事業者は手書きで対応したり、回避策のスタンドアローンで動く送り状プログラムでしのいだと思われます。
また、なぜ私が「自社基盤で」と言い切るかというと、ヤマト運輸はヤマトシステム開発というシステム子会社を持っていて、この「送り状発行システム B2クラウド」のURLが持つIPアドレスは同会社の持ち物だからです。クラウドとは銘打っていますが、オンプレミスの自社基盤をインターネットに接続しているだけです。同社もデータセンターを持っていることを明言しています。
しかも、IPアドレスが属するネットワークの名前が「NEKO-OSA-YTC」とあるので、ああ大阪にあるのねぐらいはわかります。
今回の件について、システム運用の観点から思うところをまとめます。
考察
利用者からすれば、この大事な消費税アップ直前になぜ3日間も止まったのかと不思議だと思います。機械の問題だったら保守ベンダーにすぐに取り換えてもらえばいいのではないか。アプリケーションのバグならすぐ修正すればいいのでは。いつまで待てばいいんだ。原因だけでも公開するべき。などなど。
この3日間、動いているべきシステムが止まっているというのはITエンジニアにとってとてもつらい時間です。さすがにどこかで仮眠や休憩は取ったと思いますが、システム障害が起こって解決せず、寝て起きてもまだ障害が続いているというのはメンタル的に非常に良くない状況です。
では、なぜ3日間もかかるのか。アクセス集中という言葉を聞いてとても合点がいきました。
ユーザーとアプリケーションの間には、いくつもの機器が介在しています。
・インターネット回線
・ファイアウォール
・ロードバランサー
・物理サーバー
・それぞれを接続するL2スイッチ
少なくとも上記の機器は存在していないとインターネット向けシステムは動きません。
このシステムがサービスインしたのは2017年です。
サービスイン前に、どの程度のアクセスを見込むかを想定して上記要素のスペックを決めていきます。例えばインターネット回線なら帯域が1Gbpsなのかそれとも10Gbpsなのか・・共用なのか専用なのか。ファイアウォールやロードバランサーならどれぐらいの通信を捌けるのか。おそらく仮想基盤で動く場合、サーバー側のCPUコア数やメモリーはどれぐらい用意すべきなのか。最大負荷を想定し仕様を決めていきます。もちろんお金をかければいくらでもいい設備は整えられますが、基本的に予算は決まっています。予算に見合いつつ想定内の負荷をこなせるギリギリの仕様を決定する。これがキャパシティープランニングと言います。
プランニングするだけではなく、必ず負荷試験も実施し想定の負荷を正しくこなせるかも測定します。もし捌けない場合は原因判別を行い必要によって機器増強をします。もしキャパシティープランニングに問題があった場合は追加費用はユーザーは持たずに、導入ベンダーの持ち出しとなる場合もあります。ですから導入ベンダーも余裕を持たせて機器選定することがほとんどです。
さて、そこまで準備したのにアクセス集中ということが起こりえるのでしょうか。これは十分起こりえます。今回のような消費税増税前のようなシチュエーションは要件に入っていないからです。アクセス集中時にはユーザーは再試行してくることも多く、通信が増大します。導入ベンダー側からすれば、想定する通信以上のアクセスが押し寄せてシステムが動かないことは「仕様」であり保守範囲外です。事前にもっと余裕のある最大負荷をユーザーが示す必要がありました。
こうなったときに、いくらシステム保守を行使しようとしてもベンダーは契約外です。むしろユーザーがベンダーにスポット費用を支払った上で急いでシステム増強をするという緊急度の高い構築案件として扱われます。
ベンダー側に緊急で動けてかつすぐに必要な実装ができるITエンジニアがいればまだいいのですが、もちろん調整が必要です。別の仕事を遅らせたり技術を持ったサードベンダーに依頼したりとここで時間がかかります。
人の調整をつけたとしても、今度は機械の調整も必要です。物理機器を性能の高いものに入れ替えると言ったって都合よく在庫があるとも限りません。またその新しい物理機器に入れ替えるとしても現在の仕様を短時間で引き継げるかどうかも調査しなければいけませんし、できるとしてもテストは必要です。
このように、オンプレミスにおけるアクセス集中というのは解決までに多くのリソース（カネ、モノ、ヒト）を必要とする大事件なのです。
もし、AWSやAzureのようなパブリッククラウドであれば、通信周り（インターネット回線や通信機器）がボトルネックとなることはほぼあり得ません。パブリッククラウド陣営の設備投資の仕方はオンプレミスのそれとは次元が違います。サーバースペックが足りないとすれば、数分でスペック変更できます。クラウドの強みはもうこれにつきると言っても過言ではなく、アクセス集中に対する耐性が相当に強いです。
ただ、パブリッククラウド側が無尽蔵にリソースを持っているわけでもないので、クォータと呼ばれる利用リソースの制限値を設け、それを超えることが予想される場合はクラウド事業者と事前に調整することがほとんどです。
それでも、あのオンプレミスのときのアクセス集中に対する底知れぬ不安感と比べればまだ全然マシな世界。
だから私はオンプレミスをやめて、クラウドに来たという理由です。
オンプレミスとクラウドの使い分け
ではクラウドにすれば何でも解決するかというと、またそれはそれで問題があります。日経にも先日のAWS大規模障害を受けて記事が掲載されておりました。
オンプレミス対クラウド、AWS対非AWSという対立軸で語るのではなく、今後適材適所を考えるべき時に本当に入ってきた印象です。
どんなに強固なクラウド基盤でも落ちるときは落ちるし、オンプレミスなら安全かというと今回のように想定外のアクセス負荷にはめっぽう弱いという側面があります。
クラウドはより「マルチクラウド」の方向、つまり複数の基盤を使い分けることが当たり前になっていくし、オンプレミスで動かすべきワークロードもはっきりしてくると思います。オンプレミスはやはり、クラウドと比べ物理的に外部と切り離すことができる強みがあります。それはKubernetesのようなコンテナ技術が伸びても同じ話です。可搬性が強くなることでもっと、いろんな基盤を使い分けることの良さが際立ってくるはずです。
インフラエンジニアは、より広範な基盤の技術を習得すべき時代になりつつあると思いますし、範囲を限定しない心構えこそ大切になる、と思います。
