はじめに
「Jip-Base」と呼ばれる自治体向けのクラウドサービス (IaaS) で障害が発生し、全国の自治体関連システムに影響が出たとのことです。
- https://www.jip.co.jp/news/pdf/20191216.pdf
- https://www.itmedia.co.jp/news/articles/1912/16/news127.html
実務を担当されているエンジニアさんは本当に大変だと思います。どのようにすれば問題を回避できたのかについて、一次情報や解説記事等から得られた情報を元に、失敗の原因と得られた教訓についてまとめていきたいと思います。
何が根本的にまずかったのか
解説記事等では、使用していたストレージ製品(Dell EMC Unity 500)に不具合があったために、結果としてデータの欠損が発生したことが言及されておりますが、基本に立ち返って考えてみると、ソフトウェアの設計に問題があったと考えられます。
IaaS という用語自体は AWS 等の Public Cloud が普及したおかげで広く使われるようになりましたが、その根底にある設計思想については必ずしも広く共有されていないと思われます。
前回の記事でも、Well-architected フレームワークについて言及しましたが、冗長化が必要な要件がある場合は、何を守りたいのかを明確にした上で、ソフトウェアを含めた全体のフレームワークの中で要件を実現する必要があります。
今回の事例では IaaS 上でシステムを実装しているので、次のように Design for Failure に基づいた冗長構成にする必要があります。
- 複数の Available Zone (AZ) を使用し、永続化が必要なデータについては AZ を跨いだ冗長構成を取る形で保管する
- Database (RBDMS等)については、Multi Master 構成、または Replication を用いて Failover ができる状態にする
- Webの静的コンテンツ等についても、必要に応じて複数の AZ に同一のデータを配置する
また、今回の事例で改めて明らかになったこととしては、どんなにお金をかけて(高いグレードのベンダ製品を買ったとして)も、機械は壊れるという点があります。
一次情報をみる限りではストレージシステムのコントローラが冗長構成になっておりますが、今回のようにファームウェアに問題があるとシステムは停止するかもしれませんし、最悪の場合はデータが欠損する可能性もありえます。
このため、あるコンポーネントが壊れても自律的にサービスが継続できるように、ソフトウェア側で適切な制御をする必要があります。また、自律的な制御を確実にするためにはデプロイをシステマチックに実施するためのツールが不可欠になってきます。
おわりに
今回は、最近発生した失敗事例を元に Design for Failure の重要性について考えてみました。RAID や NAS 等でも言えることですが、例えばコントローラを二重化したとしても、一度ソフトウェアに問題が発生すると Failover では回復できないパターンが確実に出てきます。
これらを踏まえると、高価なベンダ製品を買って安心感を得る代わりに、そのお金をシステム設計に回して適切に冗長化を実現する方が合理的だと思えます。AWS のサービスで稼働しているハードウェアの大半が ODM 製品で構成されている理由の一つも、この点にありそうですね。