レンタルサーバのZenlogicホスティングの問題について [追記あり]
少し前から、あちこちで話題になっているレンタルサーバサービスのZenlogicの問題。
6月19日頃から断続的に高負荷障害が発生、先週末からはサービスを全停止して原因究明と復旧を進めているらしいが、少なくとも7/9時点では復旧できていないらしい。
追記：7/10時点で復旧したらしいが、高負荷状態の影響はまだ一部残っているらしい。
現時点での状況
リリース記事によれば、現時点で分かっている原因は以下の通り
●冗長構成しているストレージシステム（データ記憶システム）において、データ入出力の処理が一部のシステムに偏ったことにより、高負荷が発生。該当ストレージシステムの再起動が発生し、サービスが断続的に利用できない状態が発生しました。
●データ入出力の処理が一部のストレージシステムに偏るのは、以下の点が原因と推測しております。
ー突発的なアクセス集中が発生した際のパフォーマンス不足
ーストレージシステム構築時のパラメーター設定が適切でない
阿鼻叫喚
Zenlogicを使用していると思われる、様々な個人や企業などから悲鳴が
月曜の朝までサーバー全面的に止めやがった……信じられないが本当だ……
— Toshiya Takahashi (@Kaizoubaka) 2018年7月6日
当社サーバー管理会社で不具合が発生している件について、7月9日AM8時復旧見込みでしたが、未だメンテナンスの状況が続いております。ご迷惑をおかけしております。
— エレコム(公式) (@elecom_pr) 2018年7月9日
当社としては、まず製品ドライバダウンロードページを復旧すべく、現在仮設ページを構築中です。もう少々お待ちください。
Zenlogicとは
Zenlogcを運営するのはファーストサーバ
ファーストサーバと言えば、2012年にデータ消失事故を起こし損害賠償を行う事態になったことを覚えている人も多いと思う。
【インタビュー】データ消失事故から3年、変革を決意 ファーストサーバはサーバーを捨てて中小企業の救世主となる - クラウド Watch
事故自体はスクリプトのバグや初動対応の不手際などの人為的なミスが引き金だった。
「業務プロセスを見直し」「属人化を排除」「資料のオープン化」などを進め、自社でのサーバ保有をやめ、Yahoo!(とAWS)のクラウドベースに移行しZenlogicホスティングとして「中小企業の救世主となる」はずだったのに・・・
今回のトラブルで、またあの時の悪夢の再来か・・・と言う印象を持たれた時点で企業としての信用は地に墜ちたと言っても良いかも・
トラブルを受けた意見
たまたま、はてなで興味深い見解を示している記事があった。
id:orangeitems さんの記事 www.orangeitems.com
インフラエンジニアと言ってもまたそこから役割分担があって、物理サーバーやOSに強いサーバーエンジニアと、ネットワークに強いネットワークエンジニアがいます。大昔は物理サーバーとネットワークしかインフラに無かったので、大体はこの二極化でした。
IT業界の中ではインフラエンジニアはマイノリティーであり、しかもその中でサーバーとネットワークで職域が分かれ、しかもストレージのお守りが大変負担になっている。その中で、経営者はコストを安くせい、開発者はコンテナだクラウドだと言ってくるこの世の中で、Zenlogicがストレージ周りで苦労していることは不思議ではないと思っています。
ITにおけるインフラエンジニアって、「無くてはならないもの」にも関わらず「空気みたいに扱われがち」な部分があると思います。 APやDBとは違い縁の下の力持ち的な役割が強く、その存在感が強く意識されることは少ない。
氏の意見ではストレージエンジニアってあんまいないよね、って事らしいけど、一応自分はインフラエンジニアの中でも割とストレージよりな立場なので、一応立場的には「ストレージエンジニア」的な業務をかれこれ15年くらいは続けてきた自負はある。
今回のZenlogicの問題でもIO負荷が一部のシステムに偏ったため、とあるが。オンプレミスなシステムであればまだしも、仮にもYahoo!ベースのクラウド基盤を使っていて、SDS(Software Defined Storage)化されたストレージで「システム的に」局所的な負荷がかかったところで「物理的」には分散されるべき作りのような気がするので、単純にIO負荷が高いだけの問題では無いと思いたい。
パフォーマンス問題の難しさ
インフラエンジニアとしての経験から考えると、今回の件に限らず「パフォーマンス(性能)問題」と言うのは、実はとても解決が難しい。
ハードウェアにしろアプリケーションにしろ、何らかの問題があったときにエラーやタイムアウトなどのメッセージを残す様な場合であればそれを手掛かりに調査や対処を行うことが出来る。
しかし、性能問題のやっかいなところは「遅いなりにも何とか応答を返している」場合に、どこにもエラーや証拠が残らない場合が有ることだ。
それがサーバのCPUリソースであったり、ネットワークであったり、メモリであったり、ストレージであったりする事もあるが、明確なエラーメッセージを残さないのでどこが原因かを突き止めるのがとても難しい。
こういうときは地道に一つずつ可能性を潰していくしか無い。
本来はこう言う問題が起きないように設計段階で性能を考慮する必要があるが、往々にして性能指標というのは軽視されがちだ。
Zenlogicの問題の本質がどこにあるのか推し量るのは私には分からないが、他山の石とせずに見守っていきたい。
