保守と障害の概要
ふて寝するほど話したい。この番組は、システム開発25年の株式会社プラムザが赤坂より、開発の現場の今と本音をざっくばらんに話していこうという番組になります。
進行は私、鴨志田と、代表の島田と、引き続き今回のゲストも株式会社プラムザ執行役員の辰巳さんです。
よろしくお願いします。
今回のタイトル、なぜ保守は障害が起きるのかというタイトルになっているんですが、保守における障害はどういったものになるんですか?
障害というのは、いわゆるシステムのサーバーがダウンしてしまうとか、重くなってしまうとか、使えない状態になるというのが一つの障害の大きな特徴でもありますし、あるいは情報が漏れてしまうというのも障害ではないのかな。
どっちかというと、今回のテーマにするのはサーバーダウンという話ですかね。
サーバーがダウン。それはなぜ起きるのかというところにはなってくるんですけど、どういったことで障害、サーバーがダウンとか起きるものなんですか?
そうですね。障害とかって起きないようにインフラとか一生懸命設計して作っておくんですけど、これどうしても使っていくうちにいろんな原因でサーバーって止まるんですよね。
たまたま処理が重なってメモリーに負荷がかかってしまって止まってしまうとかっていうことも最近は減ってきましたけど、昔はしょっちゅうあった話だし、
あとは外部からのアタックを受けたりとかいうこともあったりですね。
あとも完全にわけわからないということで、突然サーバーがストップしてしまって再起動したら直った、それからずっと調子が良いとかって、そんな意味不明なこともなくはないですね。
よくインフルエンサーが何かの商品を紹介してサイトにアクセスできないとかいうことも聞いたことがあるんですけど、あれも障害というかサーバーが落ちてるってことになるんですか?
それはそうですよね。急に負荷がかかって、想定していないユーザーがアクセスしてきて、それで止まってしまうということがよくありますよね。
最初の想定とかって結構大事になるんですか?障害が起きないようにするにはみたいなところだと。
そうですね。うちの場合は受託でやってるんで、お客さんと相談して、このサイトであったシステムってどれぐらいの人が利用するのかって決めるんですよね。
非機能要件とかって言うんですけど、それで決めて、そのレベルで落ちないようにしておく。メモリとかサーバー台数とかって決めておくんですけど、それ以上の負荷が10倍とか来ちゃうと止まっちゃうことがあると。
それをあらかじめ10倍とか100倍、1000倍みたいなところまで加味して作ると、予算の問題とかになるんですか?工数の問題とか大変すぎるみたいなところになってくるんですかね?
ある程度までは予算でカバーできると思うんですよね。LPSとか使ってもさ。どんどんグレードアップしていけば、それはかなりの人数のさばけたりするんだけど、ある程度以上になるとそういうレベルじゃなくなってきて、もっと抜本的にやらなきゃいけないっていうことがあったりするかもしれないね。
そこで言うと、保守費用の話で深掘りしていきたいなと思っていて、いわゆる島田さんおっしゃっていたお金をある程度払えば一定のクオリティーは担保できるけど、そこから超えても何かしらのものが出てきてしまうっていうのは全然あり得て。
僕よくお客さんに話すときに、保守の費用って一体何っていう話をするときには、保険の費用みたいなものですっていう一部話していて、それ相応のサービスを求めるのであれば、ある程度お金を払ってくださいっていう話はしていますね。
じゃあ、そこで一定のサービス、セキュリティーのこととかも含めてですけど、それができていない状態だと島田さんがおっしゃっていたセキュリティーのアタックが起きて、それによってサーバーがダウンしてしまうっていうのは考えられることなんで、お金をたくさん払えと言ってるわけではないですけれども、それがある程度ないと障害起きてしまうことはあり得るのかなと思っています。
炎上は起きるべきして起きるんですけど、障害って本当に不発というか突発的に出てきてしまうものだったりもするので、そこの回避の仕方も全然アプローチが違ってくるのかもしれない。
なるほどですね。確かにサーバーにつながらないって1ユーザーとして考えると結構大丈夫かってなってしまうんですが、そこら辺は場合によってはしょうがないっていうことも多々あるっていうところと、保険っていうのは結構イメージしやすいなって思いましたね。
こんぐらいの金額の掛け金があるからこんぐらいのところまで保証できますよっていうところは確かにイメージしやすいなっていうのを今聞いていて思いましたね。
そこで言うと、障害が起きてしまうっていうところを起きないようにするっていうのも大事なんですけど、起きたときにどうやって早く復旧するかっていうのがすごい大事なポイントだと思っていて。
例えばですけど、SLAとかSLOとかよく言われていて、サービスレベルアグリーメントとか、Oが何でしたっけ、オブジェクトか。
いわゆるサーバーが落ちたときにどのぐらいの時間で復旧をさせるべきかみたいな取り決めみたいなものですよ。
これも専門的な用語ですけど、非機能要件の一部に多分入ってくると思うんですけど、システムがどういう速度とかでどういう規模で動くべきかみたいな話です。
さっき島田さんが言っていたどれぐらいのシステムを使う人がいるのかとか、例えば1週間で言ったら平日だけ動いてればいい。平日の日中だけ動いてればいい。
逆に24時間ずっと動いてなきゃいけないのかみたいな話ですよね。
なるほどですね。ちょっと漠然とした話になるんですけど、聞いていて障害って守れないもの、どうしても起こるものっていうことだったんですけど、
考えてみれば、たまにニュースとかですごい大手さんとかでも結構サーバー落ちたり、システムのエラーがありますみたいなことってあったりするんですけど、
大手さんはお金とかしっかりかけてるはずなのに、やっぱりそういうことが起きるんだなという話を聞いていて改めて思いましたね。
ニュースで出ていますし、実際に。上々企業とかだったらコーポレートサイトで障害報告書みたいなのがよく出てますね。
障害が起きた際の対応
直近でかいところで言うと、某大手プリンで有名なメーカーさんがシステムの障害が起きて、結構な期間商品の出荷ができなくなってしまう。
有事例があるんですね。目に見えないところでいろいろな障害がたぶん日夜起きていると思いますね。
どうしても防げないものっていうのは、そう考えると何でしょうかね、腑に落ちてくると言いますか。
セキュリティ対策してないわけがないと思うのですけど。
データセンター側でもですね、障害が起きるんで、一概にこちらのアクセスがね、ユーザー間のアクセスが変わってくれたり、
システムに負荷がかかってというよりも、もうちょっと上のインフラのですね、
AWSとかGMOとかそういうところの方でスーパーバイザーが落ちてしまうとかってなると、システムダウンしてしまうんですよね。
こちらの努力ではどうにもできないっていうことがあるんで、さっきちょっとちらっと言ったんだけど、
ある程度まではカバーできるっていうのは、例えばAWS使ったらAWSの中でサーバーをね、
冗長化させておいて切り替えるとかってできるんだけど、
AWS全体がですね、もしも落ちてしまったり、アクセス不能になってしまうと、それはどんなにAWSの中で冗長化してもダメなんで、
AWSとGMOとかの別のクラウドサービスと両方持っておくとかっていう風にしないといけない。
そういうこと考え始めると、もういくらでもお金がかかっていくので、データベースの同期とかね、いろいろしないといけないんで。
実際になんかそれこそ報酬の要件を満たすためのチェックリストを記入してくださいっていう風にお客さんから言われたときに、
AWSが世界各地にありますけど、指定していたそのリージョンですよね。
そのサーバーを置いている場所、使ってるサーバーが置いている場所で戦争が起きた場合どうなりますかみたいな。
大震災とか大災害、自然災害が起きたときにどうしますかって。
いや、どうしようもないと思いますっていう回答をせざるを得ないっていう。
確かに防災の感覚に似てる気もしますよね。対応とかできる範囲のことをするしかないと言いますか。起きるときは起こってしまう。
それもやっぱり別の国に2つ用意しておくとか、日本国内であってもフォッサマグナを挟んで東西に分けて複層化しておくとかっていうのもあるんで。
そういう対応って考えられはするんだけど、考えれば考えるほどキリがなくなって、
いろいろ考えるとどんどんお客さんの方も不安になってきて、大丈夫なの？みたいな感じになってくるんで、あんまり言い過ぎてもいけないんだけど。
大きな話でもそういうことで障害が起きますし、あとはプログラム単位で進行不能なバグが起きてしまったりだとかは全然ありますね。
直近も僕も障害を起こしてしまって、2日間寝ずの対応をしたりとか。
あとは何でしょうね、エンドユーザーさんで意図としない操作をしてしまってデータがめちゃめちゃになってしまうとかも。
それこそ意図としない挙動でものすごいメモリー圧迫してしまって落ちてしまうってことも全然あり得る。
ループ処理みたいなものはマニュアルでやってしまったみたいなこととか。
話せればありますよね。
島田さんはどういった障害があったのかなっていうのを聞きたいなって。
障害発生時の対応と顧客コミュニケーション
アプリケーション的な不具合とかで障害が起きるっていうのは結構あって、テストの段階では発覚しないんだけど、データが増えていくとどんどん処理が重くなっていって。
お客さんが思い通りに重たいなと思って我慢して使ってると最後落ちるっていうね。
それは簡単に復旧できる時もあるし、できないこともあって、そうそう一生懸命直さないと直らないってこともあって。
本当に小さなことで大きな障害が起きること全然ありますし、あともっと言うと、どれだけ障害の対応に時間がかかるかって本当に物によるんで。
当然一生懸命直すんですけど、本当にさっき言ったように2日かかる時もあるよ。
その2日も結局直しようがないものだったんで、徒労に終わったってことも全然あるんですけど、それこそ保険に対して病気とか事故とかが起きた時に、
どれだけ対応しても無駄だってこともあるし、一瞬で直ることもあるっていうのがすごくいい得ている思いますね。
なるほどですね。その中で障害に対してお客様とどう折り合いをつけるかっていうところもあると思うんですけど、どういった対応がベストになってくるんですかね?
これは僕、島田さんの考えを聞いてみたいですね。
そうですね。お客さんへの啓蒙というか、一緒に意識合わせする必要があると思うんだけど、システムって車とか電化製品と違って必ず障害が起きるんですよね。
それをちゃんと理解しておいてもらって、障害が起きた時に一緒になって戦っていくっていう姿勢が大事なのかなって思って、
お客さんでないとできないこともありますし、例えばエンドユーザーへの報告とかですね。
こちらはこちらで一生懸命直すんですけど、お互いに責任をなすりつけてもしょうがないので、できることを対応していくっていう感じになりますよね。
やっぱりいい関係を作っていくためには、こちらも透明性を持って報告しないといけないし、あらかじめお客さんとそういうことが起きるので、
そうしたらどうしましょうかっていうのは、そういう障害の対応フローを一生懸命考えておくっていうのも大事だったりしますよね。
お互いに気持ちを冷静に収束させることに意識を集中させるっていうのが一番大事。
最後は本当にお金の話になってきたりするんだけど、シビアな話もありますね、そういう意味ではね。
クラウドサービスと保守料金の見直し
そうするとイメージとしては起きる前に何をするかというよりも、もちろんそこも大事かもしれないんですけど、
その後どうするのか、起こったときにどう対応するのかっていうことをあらかじめ共通認識を持っていたり決めておくってことは結構大事になってくるんですかね。
そうですね、その辺の共通認識を持っておいてチームとして対応していくってことが大事かなと思いますね。
あとこれは個人的にちょっと気になったんですけど、さっきAWSとかGMOサーバーとか自体落ちることもあるよってあったんですけど、
たまに自社サーバーっていう、自社でおそらくサーバーを持ってるっていう会社さんあると思うんですけど、
そういう場合の障害がやっぱりそっちの方が起きやすいものなんですか。
セキュリティ的にはそっちの方がセーフティーだったりするものなんですか。
セキュリティ的には自社の中でやった方が外部からアタックされるっていう心配は少ないですよね。
ただやっぱりクラウドじゃないので基本的に社内に作るってことは、そうすると落ちやすいのは落ちやすいですね。
可動性が低い、大きくスケールアップしたりだとか、あんま使わなくなったらスケールダウンしようかっていうことがあまりできにくい。
あまりできないですよね。もう決めたハード以上にはスケールアップできないし、ダウンもできないし。
すぐにできないものですよね。やっぱり機材を調達してっていうところから。
確かに物理的に置くってことですもんね、自社、サーバー。
なるほど。クラウドの方がそこら辺の拡張性、増えてきたら増やして、減らしてきたら減らすみたいなところとかがしやすい。
極論、クラウドの業者でも自社データセンター持ってるってことは、自社でいわゆる自前のサーバー、オンプレミスって言うんですけど、
それを抱えていて、それを借りているっていう状況なので。そこは持ち屋と言いますか、プロに任せておくっていうのが一つで、
っていうところだと使いやすさの観点から、最近はクラウドのサーバーを利用することが多いという話ですね。
最近、プラムザでは保守料金見直し隊っていうサービスを展開しようとしていて、
今、サービス紹介のページをリリースしたところだと思うんで、それをどんどん広めていきたいと思ってるんだけど、
お客さんのところで、保守とか障害とかをたくさん、保守とかやってもらってるんだけど障害起きるなとか、
全然何やってもらってるかわかんないなとか、高いなみたいなことがあれば、うちのほうを見させてもらって、
本当にその価格適正なのか、ちゃんとやってくれることやってるのかっていうようなことを診断しますよって。
やってないようであれば、うちのほうでやっていきますよっていう、引き受けますよっていう、
そんなサービスを展開しようとしてるんで、もし興味があればググっていただいて、
概要欄のURLに掲載したら。
書いてきますんで、そちらをご覧いただけたらと思います。
では、こんなところで本日はよろしいでしょうか。
本日はいかがでしたでしょうか。楽しんでいただけましたら、フォローや評価をお願いします。
また、Xでも最新情報を随時発信していますので、よろしくお願いします。
システム開発に関するご相談がございましたら、公式ホームページからお気軽にお問い合わせください。
それではまた次回お会いしましょう。
ありがとうございました。
ありがとうございました。