メンテナンスの重要性
こんにちは、シニアソフトウェアエンジニアのriddleです。
こんにちは、リドルソフトウェアエンジニアのひびのです。
このポッドキャストでは、僕たち2人でキャリアに関することだったり、技術に関すること、普段の仕事に関することなど、IT業界に関する様々なことを話して、リアルを届けていこうという趣旨の番組でございます。
今日のテーマが、あのサービスがメンテナンスする時、裏では何が起こっているのか？、です。
メンテナンス、メンテナンス、僕実はメンテナンス結構好きなんですよ。
あ、なんでですか?
だって、夜中に同僚とみんなで集まるとちょっとワクワクしませんか。
ああ、まあ別に夜中限定じゃないかったからな。
ああ、そうなんですね。僕が経験したものによるだもん。サービスによるだもん。
確かにそれはありそうですね。
ちなみにリドルさん、これまでメンテナンスって何回も経験されてきたと思うんですけど、そもそもまずどのサービスでメンテナンス経験されましたか?どういうサービス?
えっと、もともとSIR時代の時には、某携帯キャリアさんのシステムとかですかね、それは深夜に止めてましたし、ミクシーに入ってからは早起げ屋さんで、早起げは全然昼間に止めたりするので、それとか。
あとオーストラリア向けのベッティングサービスとかですかね。ひびわさんは?
僕はメンテナンスを経験したのは、ミクシーに入って一番最初のウェブサイトですね。利用室の。
深夜止めたんですね。
はい。その時のメンテナンスはおっしゃる通り、全部深夜でしたね。
じゃあ、終わる頃は明け方みたいな感じですか?
いや、そこまで時間かかるものは少なかったですね。
まあ、覚えてる範囲だとだいたい、スケジューリングとしては、夜深夜2時にスタートさせて、
まあ、ただそこからだいたい、そうだなあ、長引いたとしても2時間と少しくらい?
まあ、基本的に1時間以内に終わる作業がほとんどだったかなと思いますけど、
なんか深夜にやっていた経緯としては、おそらくお客様向けのウェブサイトも提供しているけど、もう一つビジネス向けのサービスも提供しているから、
だからそのデータベースの作業とか、まあシステム全体を止めるとなると、ビジネスに影響を与えない範囲でやらなきゃいけなかったっていう事情はありましたね。
うん、まあ確かにそうなりますよね。
で、そうか、実際に何をやっているか、裏では何が起こっているのか。
そう、いやこれだってね、咀嚼とかよく日中帯とかにメンテナンスやってて、メンテナンスが伸びると結構阿鼻共感する方もいらっしゃるじゃないですか。
そういう人からすると何やってるのか全然わからないけど、とりあえず伸びてて後で詫びしてくれるみたいな、謎のそういうキャンペーンみたいになってるじゃないですか。
確かにそうかもしれない。
そもそもリドルさんがやってた咀嚼でのメンテナンスっていうのは、なんかそれこそ何だろう、問題が起こったからその時対応しなきゃいけなくてやっているのか、
それとも事前に何だろう、例えば僕の経験ではメンテナンスって大体データベースのバージョン上げるとか、
データベースへのアクセスを1回止めなきゃいけない類の理由が多かったんですよ。咀嚼だとどういう理由でやることが多いんですか。
咀嚼はまずですね、ひめのさんがおっしゃるような緊急的なものもあるんですけども、するよりも定常的に上げるっていう作業が多いんですよ。
定常的に上げるというのは。
これ何を言ってるかというと、咀嚼ってだんだんその機能が増えたりとか、なんかモンスターが増えたりとか、アイテムが増えたりするじゃないですか。
で、これってどういうことかというと、新しいバージョンのアプリを開発してたりとか、新しい機能をどんどん作っているんですね。
で、そうなるとですね、普通、例えばAPIとかの話をすると、APIって何かご法御反省があって、別に多少古いものを使ってても大丈夫みたいな話があったりすると思うんですけども、
ユーザーに提供しているゲームって全員が等しく同じバージョンで遊んでほしいんですよ。
そうすると、アプリのストアに新しいアプリを出した上で、かつサーバーもそれに対応した新しい機能を持ったAPI組にして、
かつユーザーにダウンロードしてもらうマスターデータって呼ばれるクソ重たい何ギガみたいな画像とか音声とかいっぱい入ってるやつがあるんですけど、
それも全部新しくしたっていうのを全部込みでユーザーに落としてもらって、次回のバージョンのものが遊べるっていう方式になっているので、
メンテナンスの作業中にそれらを全部用意して、用意できたらメンテナンスを開けてユーザーがダウンロードして遊ぶみたいな感じなんですね。
なるほど、今一つ疑問に思ったんですけど、例えばメンテナンスモードに入れなくても、
例えば何月何日何時時点で新しいAPI、新しいデータ、新しいアプリが公開されます。
そのタイミングになったら新しいバージョンにアップグレードしてください、アップグレードしなかったら使えませんみたいな、
何というか明示的にメンテナンスモードにしなくても乗り切れる方法はあるんじゃないかなって思ったんですけど。
ありますし、実際にそれをやってる会社さんでコロプラさんというところはノーメンテでやられてたりもしますね。
ただやるとなるとやっぱりある程度技術的な難しさもありますし、いろんなところでミスがリカバリしづらいみたいな問題もあるので、
数時間止めるぐらいだったら安全に倒してメンテナンス入れるような感じにしようかっていうのが割とよく聞く話ですね。
なるほど、むしろメンテナンスに入れる方がより安全に運用できるっていうことなんですね、そのバージョンアップについては。
そうですね、要するに過渡期の複数バージョンが混在しているときのことはあまり考えなくていいので。
なるほど、確かにそうかもしれない。
そういうこともあって、全部ドキナミにいろんなことやってから出そうみたいな感じだったりだとか、そういうのって日中帯にやるんですけど、
プランナーの方がいてとか、デザイナー関係ないかな、クライアントの方がいてとか、それは何かがあったときにもその場でリカバリがなるべくできるようにということだったり、
夜中にやると限らない人数でしかできないので、だいたいもう昼間とかにやっちゃうんですよ。
ゲームっていうサービスの性質上、平日の昼間の方がむしろユーザー少なそうではありますもんね。
厳密に言うと昼間は昼休みでやる人いるんで、それ終わってからとかそういう時間なんですけど、確かにそういうユーザーが少ないっていう時間帯でもありますね。
18時までに終わらせて、それから夜にできるようにするみたいな。
ウェブサイトのメンテナンス
定期的にメンテナンスの予定を入れとくことで、例えばOSのバージョンアップをしないといけないとか、ソフトウェアのアップデートをしないといけないっていうのも一緒にそこに混ぜ込んじゃうみたいなこともありますね。
そうですよね。例えば、何だろう、AWSの都合でこのインスタンスを何日までに入れ替えなきゃいけないみたいな、そういう細かい都合のアップデートもそこにもう同時にやってしまうみたいなことができるわけですね。
そうですね。
確かに。
あと何だろうな、そのウェブと違ってですね、デプロイ頻度が要するにそのメンテナンス単位なんですよ。
なるほど、なるほど。
例えばウェブって今だとトランクベースの開発ってありますけど、そのGitHubとかのメインブランチにマージしたらもうすぐリリースされるよみたいな。
ちょっとミスったらリバートして戻せるよみたいなことが結構一般的かなと思うんですけども、ゲームの場合って、例えば毎月1日に新しいバージョンを出しますみたいな感じになってたりするので、
そうすると毎月1日にリリースをするっていう感じで、裏でスケジュール走ってクリエントもサーバーもデザイナーもみんな動くみたいな感じなんですけども、
それのラインが複数あるんですよ。1ヶ月後に出すやつと2ヶ月後に出すやつと3ヶ月後に出すやつみたいな。
はいはいはい。
開発ラインが複数あるので、サーバーも即時デプロイするというかはそれに向けて準備するとか、インフラもそれに向けて準備するとかそういうことがあるので、
メンテナンスでいろいろ作業するみたいなのが多くて、だからそこでトラブルとめっちゃ大変って感じですね。
へー、それすごくなんか興味深いですね。それこそ僕の弊社、ミクシーだとゲームをやってる部門とあとウェブサイトを運営してる部門とあって、
僕はまだゲームをやってる部門で働いたことはないんですけど、そうかフロアが違えばそういう開発スタイルが採用されてるんですね。
そうですね。
面白いな。
ウェブはどんな感じでしたか?
ウェブはそれこそリドルさんが説明したゲームとは結構対照的で、やっぱり理想としては常にお客さんがウェブサイトを開ける状態が理想ですよね。
なので本当に極力必要がない限りはまずメンテナンスは入れないが基本的な考え方で、とはいえ例えばさっき話したようにデータベースのバージョンアップだったりとか、
あとAWSのこのインスタンスを何月何日までに落として新しく立ち上げ直さなきゃいけないからとか、なんかそういう都合でどうしても落とさなきゃいけないタイミングが来たら一回深夜にメンテナンスモードに入れて、
大抵1時間時間は取っているけど、ちょこちょこと作業して終わるくらいのものがほとんどなんです。そういう感じで数ヶ月に1回メンテナンスを入れるっていうのが基本でしたね。
ちなみにメンテナンスでやる作業って事前に練習したりとかするんですか?
やりますね。それこそ何だろう、例えばデータベースのインスタンスの入れ替えだったりとか、そういう類のものは事前に手順書をまず作成します。
その後に実際に使うインフラ、同じサイズのインスタンスを立ち上げて、どれくらい時間がかかるかをあらかじめ計測しておいて、これくらいの時間取れば問題ないだろうっていうことを手順を含めて、これくらいメンテナンスに時間取るので、
ビジネスサイドとカスタマーサイドにお知らせを出してくださいみたいなことを企画の人にお願いして、あとは決められた日にシニア、ニジニア、エンジニアがリートに集まって作業するみたいな感じでしたね。
いいっすね。自分が最初にエッサイヤーでやってたのもウェブサイトだったんですけども、なんかすごいでかくて、たぶん最大で1000万人ぐらいユーザーがいるみたいな、そういうバカデカサイトっていうかもうなんかそういうものだったんですけど、その時はお客さんのサービスなんで同じくシニアにやるんですけど、
なんか運用してから10年以上経ってるサービスだったっていうのもあって、もうガチガチにいろんなことが決まってたんですね。これはなんか要するにミスを起こさないための工夫みたいなものが随所に盛り込まれていて、まずタイムテーブルみたいなものを作るんですよ。
タイムテーブルを。
タイムテーブル。要するにそのメンテナンス入れてからこれやってあれやってみたいな複数の作業があるわけじゃないですか。で、それを全部事細かにこういう作業を何分でやります。開始時間何分で終了時間何分ですとか、なんかそういうのバーって書くんですね。エクセルで。
で、それと手順書を作るんですよ。本当にテキストで。コマンド一行一行レベルの。それ以外はやりませんっていう手順書。
で、これをまずベースにレビューしてもらって、レビューオッケーになったらステージング環境で一回レビューする、レビューじゃない実際にやるんですよ。リハーサルとして。
で、そこで時間とかがちょっと変わったらその時間を更新していくんですね。で、プラスですね、切り戻し作業っていうのをやるんですよ。
切り戻し作業。
タイムテーブルが例えば20個向かうとするじゃないですか。どこでイレギュラーが起きてもいいように、そこから元に戻すための逆のタイムテーブルを作るんですよ。
それは何か何だろう、途端にパターンが党媒で増えるじゃないですか。
そうですね。で、逆の手順書を作るんですよ。戻すための逆のコピー。
メンテナンスの基本手順
手順が何だろう、1から10まであるとしたら、その2から1に戻す方法から5から順番に1まで戻す方法、そして10から順番に1まで戻す方法まで網羅されてるってことですね。
そう、でも10から1まで戻す手順が1個あれば、一応全部できるはずなんで、理屈的には。
そうかそうか、確かにステップごとに戻す段階を用意していれば。
なるほどなるほど。
で、その逆の切り戻しの作業のリハーサルもして、それぞれ1日ずつやるんですけど、その2日間で出たログを全て集めて、問題ないログが出てないかを全てチェックするっていう。
大変だ。
それを携えて実際本番に行くと、だいたい知らない問題が出してくるんですね。
それは大変だ。
そうすると即上司に電話する、こういう知らないログ出たんですけど、深夜3時ぐらいに出ます。
今の話聞いて思ったんですけど、例えば10年運用してるとはいえ、さすがにOSとかミドルウェアのバージョンアップとかはしなきゃいけないじゃないですか。
その10年前と同じコンディションのものを使い続けてるわけにはいかないじゃないですか。
そうなると、なんだろう、コンディションが違うログが出るとか、あとはあり得るとしたら手順書に書いてある画面が徐々にマイナーアップデートされていくとかあり得るのでは。
いや、なんで、ステージングと本番はもうほんと全部同じバージョンなんですよ、ミドルウェアとかも。
なるほど。
だから原理的には同じことになるはずなんで、それを維持するためにも結構お金払ってるんで。
ログを収集してっていうのは、都度メンテナンスに入れるタイミングのステージングのログと本番のログを照らし合わせて問題がないかっていうことを確認するってことですね。
いや、どっちかっていうと、リハーサルをした時にステージングであるんですけど、ステージングで出たログを全部リハーサル終わった後に回収して、
そこのログで、インフォログは置いといて、ワーンとかエラーとかで変なものが出てないかみたいなのをリハーサル終わった後チェックするんですね。
で、そこで問題があったらメーカーとかに問い合わせて、何ですかこれはみたいなの聞くんですけど。
なるほど、メーカーか。
そう、メーカーに聞くんです。本番では同様にログは見るんですけど、別に比較するというよりかは、テイルとかでエラーとかワーンとか出てないか見て、
いや、見たことあるエラーとワーンだったら問題ないんですけど、見たことないやつだと、エスカレーションというか、情緒に電話しないといけない作業中だみたいな。
なるほど。僕らの普段の感覚からすると途方もない作業に思えますね。
そう、途方もないんですけど、僕のファーストキャリアはそれなので、それが当然だと思ってた。
ちなみになんですけど、ステージングでリハーサルするときは、例えばログで出てくる情報って、言ってみたらデータベースだったりストレージだったり、その中身のデータによっても変わってくるものだと思うんですよ。
それも全部スナップショット撮ってくるってことですか?
そうです。全部スクリプトがあって、すべてをExcelに貼り付けて。
それはいいけど、1000万人オーダーのユーザー数がいるサイトでやるの、それはそれでまた途方もないですね。
でも別にあれなんですよ。ユーザーがアクセスしてるわけじゃないメンテナンスでやってるから。
出てるログは別に、僕らが何か作業した結果としてのログしか出ないので、基本的には。そんな大したものはないですね。
なるほど。
数万行ぐらい。
ちなみに、本番のデータベースを止める前にリハーサルやるってことは多分あれじゃないですか。スナップショットを撮ったタイミングとは絶妙に差異があるわけですよね。本番のデータっていうのは。
リハーサルってあれですよ。全然1ヶ月前とかそうやるの。
そうか。じゃあもうそこは織り込み済みなんですね。
そうですね。だからタイムスパンがWebとは全然違うんですけど、Webって予定してからやるまでそんなに間ないと思うんですけど、我々の話は1年とか2年とかする話なので、何かをやるという作業か。そのクライマックスとしてメンテナンスを入れる作業があるので、ちょっと違うかも。
そうか。1年かけてメンテナンスのための準備をするみたいな。
そう。1年かけて新しい物理サーバーを入れたりするんですよ。
そっか。しかもオンプレなんですね。
そう。だからデータセンターの話です。これ。
なるほどなるほど。そうか。確かに物理的に入れ替えなきゃいけないとなると、もうそれは大きなプロジェクトですね。
そういうこともあって、今そういう案件は減ってると思いますけど、日本のどこかには全然あると思うんで。そういうこともあったりしますよね。メンテナンスは。
クラウドネイティブ時代の進化
そう考えると、僕の世代は改めてクラウドネイティブの世代だなって思いますね。
そうっすね。めっちゃ楽っそうね。今サーバーレスとかも多いですね。自分も設計するときはサーバーレスを多くしてるし、クラウドスパナーとかなんてデータベースとしてのバージョンアップとかもいらないし、隙間の変更もオンラインでできちゃうから。全然。
そう考えるとあれですね、もう本当に10年、20年の間にメンテナンス作業っていうのもだいぶ楽になったもんですね。
いや、ほんとですよね。ミドルウェアのバージョンアップとかも全然、なんかね、ディペンダフォッドとかリロベートとかでちょこちょこってやって勝手にレポリされるから、全然あんまり気にしないですよね。
いい時代になった。
まあちゃんとセマンティックバージョニングみたいなのが普及したのが大きいっすね。
ああ、確かに確かに。まだまだセマンティックバージョニングなんてものを無視してるパッケージもあるはありますが、
JSは怪しいっすね。人が多すぎる。
NPMパッケージは、なんだろう、平気で破壊的な変更入れてきますもんね。
NPMは最近セキュリティ的なサプライチェーンとか多すぎて、ちょっとなんか怖いっすね。
まあね、NPMに限った話ではないと思うが、よく問題起こしますね。
あんまり他の聞いたことないんで。
まあでも仕組みから言ったら、まあ平たく言うと、なんだろう、ホームブリューにも、あとはなんだろう、GOパッケージのトジトリにも、まあ仕組みは同じだから同じような問題はあるはずじゃないですか。
まあちょい厳密にはGOパッケージは別にリポジトリはないんですけど、
まあでもLinuxもね、aptとかyabとかそういうのもね、RPMとかはありますからね。
なんか理屈はあるんですけど、あんまり話聞かない。
いやまあちょっと自分がウォッチで聞かないだけかもしれないですけど。
まあなんだろう、それだけNPMパッケージが広く今使われているっていうことですね、きっと。
そうですね。ちょっとなんか話がだいぶ過ぎちゃいましたが、ちょっとメンテナンスの裏側ではですね、いろんな変遷などですね、大変な作業があります。
はい、そうなんです。
で、もともとメンテナンスは結構バッファーを取ってやってるんですけども、それが超過するということはですね、なんか何かやばい何かが起きてると。
いやありますね。
なので本当は我々がお金をもらいたいんですけど、なぜか我々がお金を払わないといけないという、詫びですね。
まあもちろん迷惑かけてるのであれなんですけど、ちょっと許してください。
大変なんでね。
はい、ということで今回はメンテナンスの裏側を紹介しました。
このポッドキャストではハッシュタグライティで皆様からの感想やコメント募集しております。
またチャンネルの概要欄にGoogleフォームのリンクもありますのでそちらからのご投稿も大歓迎です。ありがとうございました。
ありがとうございました。
