SysAdTechBlogtemmaこんにちは、19Bの@temmaです。普段は、部内サービスの開発・運用を担当するSysAd班というチームで活動しています。SysAd班このページではtraPのSysAd班について紹介します。Administrator”の略語で、直訳するとシステム管理人のことです。この言葉から分かるように、SysAd班は主にサークル内での交流や開発を支援するための活動を行なっています。‌‌まずはSysAd班で開発している主なサービスや利用しているアプリケーションについて紹介していきたいと思います。SysAd班で開発しているサービスここでは、SysAd班が一から制作し、運用しているサービスについて紹介します。所在地と設備を確認したい方はこちらから東京工業大学インスタンスのひとつ「S512」には、サービスの中でも特に重要な部内SNS「traQ」と部員管理システム「traPortal」、認証基盤「pipeline」がデプロイされています。ArchLinuxくん...SysAd班では、これらVPSのOSにArchLinuxを採用しており、当時のカーネルバージョンは5.12.3-arch1-1でした(たぶん)。releaseを採用しています。releaseの利点は、細かな修正も頻繁に更新されることです。ディストリビューションのリポジトリから常に最新のカーネルと最新のソフトウェアリリースを入手できます。一方で、これにより、新しいソフトウェアに予期しない問題が発生する可能性もあります。releaseでは十分なQAを実施しディストリビューション独自のパッチを当てたりします。-Syuu†)、kernelのバグを踏む頻度も高くなっていました。S512(5.12.3-arch1-1)も例にもれず、slabが時間とともに肥大化する問題に悩んでいました。簡単な調査も行いましたが原因ははっきりせず、とりあえずパッチが当たるまでは、定期的に手でrebootをかける力技運用で対処していました。usageのアラートが深夜帯に被ってしまうと、健康優良児の多いtraPでは誰も気づきません。7月3日、ついにmemoryを使い切ってインスタンスが動作しなくなるインシデントが発生してしまいます。自動化しようこんな状態では夜もおちおち眠れません。労働は雑魚と誰かが言っていましたし、こういう単純作業は自動化しましょう。思ってたら、メンバーが以下のようなserviceを書いてくれました。rebootを実行するというものです。3:30:00Persistent=true[Install]WantedBy=timers.targetパッと見た感じは問題なさそうです。問題なさそうなので、そのまま本番環境に適用しました。動作確認しよう本番環境に適用する前には、必ず適切な動作確認をしましょう。行けません、今から寝ます。言うわけにも行かないのでDiscordに行くと「S512落ちてます」と言われました。何が、原因だったのでしょうか?とりあえずGrafanaを見に行きます。03:30...見たことのある数字だ...。daily_rebootserviceが実行されるのがこの時間だったはずです。再起動に30分もかかることは考えにくいです。SSHもできないので、ConoHaのコンソールから再起動してみます。一つ候補として、何らかの原因でrebootが繰り返されている場合が考えられます。ConoHaはコンソールから、VPSのシリアルコンソールにアクセスできるので、見てみると確かにrebootを繰り返しています。どんな記述が悪さをしているんでしょうか?再度Unitファイルを確認してみます。ドキュメントを残そうS512にはアクセスできなかったので直接設定ファイルを確認することは出来ませんでしたが、daily_reboot導入時の背景や手順はwikiのopsに記録されていたため、確認が楽でした。3:30:00Persistent=true[Install]WantedBy=timers.targetPersistent=trueこの記述が怪しそうです。その一回が実行されていない」場合、その時間を待たずにすぐさま実行するようです。rebootが完了扱いにならなかったことが原因で、Persistent=trueによって再度トリガーされていたわけです。しよう原因がわかったところでどうしましょう?考えてみますが、このインスタンスを自力で復旧するのは難しそうです。GRUBを使用することはできましたが、その時はうまい方法を思いつきませんでした。いい方法を思いついた方は教えていただけると嬉しいです。2021仕方がないので新しいインスタンスを立てることにします。インスタンスが立てば、Ansibleを実行するだけなので「まあ、すぐ復旧できるか」と思っていました。おいおいおい、おいおいおいおい、おいおいおい。ここで選択肢は3つです。自分のアカウントで立てるS512を消して、立て直すステージング用サーバーのアプリを止めて、そこにデプロイする順当に「自分のアカウントで建てるか〜」と思いました、が、そういえばマネージドDBへのアクセスをプライベートネットワークに制限しています。DBのアカウントはサービスごとに発行しているので、若干面倒だなと思いました。面倒くさがらずに安全な方法を取ろう1つ目の間違いです。考えてもアカウントの設定いじるほうが楽です。俺くんのバカ!SysAd班では安心してオペレーションできるように、殆どのデータのバックアップを取るようにしています。バックアップが取られていないものを洗い出した際のissueを確認してみます。「S512にローカルデータがあるよ」なんて記述はどこにもありません。救えないS512だし消して良いやと思い、気持ちよく消しちゃいます。さよなら、ありがとう、S512バックアップは残しておこうどれだけ考慮しても考慮漏れはあります。普段しないことをするときは、バックアップを極力残しておきましょう。ちなみに、時間かかるから良いやって思ってイメージの保存をしなかったのですが(2つ目の間違い)、イメージをマウントすればローカルのファイルを吸い出せるのでしておくと良かったです。さあ!インスタンス立てちゃうぞぉ〜〜〜〜!!まあ、正直半分ぐらいは予想してました。(じゃあ、おとなしく自分のアカウントで立てとけと言う話ではあったね)ステージング環境を止めてゴニョゴニョするぐらいなら、自分のアカウントで立てたほうが明らかに楽なんですが、インスタンスを消してしまった以上、ここで引いたら†負け†です😤ゴニョゴニョやって、デプロイまで漕ぎ着けました。̆)スヤァ動作確認時には、ブラウザキャッシュを削除してファイル周りを重点的に確認しました。投稿画像のサムネイルが欠けていましたが、ローカル保存ということは認識していたので問題なく、それ以外もうまく配信されているようでした。最高の夜明け🌄また、俺なんかやっちゃいました??確認してたときは、動いてたんだけど?もう駄目です、知りません。言いながら、メッセージを読み進めるとなんだか色々復旧してくれていそう。(ありがとう...ありがとう...)サムネイルは時間がかかりますが再生成できるので再生成、スタンプ用の画像は以下のスクリプトでキャッシュから吸い出してすべて復旧出来ました。ちなみに僕は寝る前の挙動確認時にキャッシュを消してるので1mmも力になれません、ごめんね。}}console.log(failed)問題はユーザーアイコン用の画像です。現役ユーザーのアイコンはそれなりに残っていたのですが、すでに引退した人のアイコンはほぼ表示されないのでキャッシュにも残ってないです。なくてもいいじゃんと思うかもしれませんが実はブログの筆者としては表示され続けるんですね...😢ありがとう、でっていう。君のおかげだ、でっていう。「でっていう」くんはtraPのメンバーです。彼がユーザーのアイコンでモザイク画を作って、素材をすべて手元に保存しているなんてことをしていなければ、引退したユーザーのアイコンは救出できませんでした。ちなみに、アイコンにはgifなども使用でき、mimeがDBに保存されています。疑問点なぜ再起動用のunitが完了扱いになっていなかったのか?というか、Ubuntuでは期待したように動くのにArchでは実行済みにならないのか。わかる方教えて下さい。動作確認時に正常に動いているように見えたのか?これはなんとなく当たりが付いています。Reloadでは消えないのでここを消し忘れたのかなと思います。Overflowtjchecketts再発防止SysAd班ではこのようなインシデントが合った際にはポストモーテムを残すようにしています。問題点などがまとめられています。unit、それをデプロイするansibleを書いてもらいました。話の発端であるカーネルのバグについてはそもそもArchのメンテナンスコストが高いように感じたので全インスタンスをUbuntuに移行しました。あといっぱい「対応の問題点」を書きました。Qiita再発防止策を書くのは難しい。GitHub.GitHubtraPtitechまとめ夜は寝よう。朝起きて対応しようね。VRChatの始め方、歩き方。