CNTOM2022で発表したモバイルコア運用引き継ぎのお話

これはBBSakura Networks アドベントカレンダー2022の 17 日目の記事です。

こんにちは。BBSakura Networks 株式会社開発本部の佐藤です。気が付いたら 23 日でした。12 月もそろそろ終わりですね。

今年の 11 月に開催された CNTOM2022 にスポンサー枠で登壇しましたので、発表準備の過程で考えていたこと・発表後に改めて思い返したことを書きます。発表時の資料はこちらになります。

発表時に伝えたかったこと

当日は「クラウド基盤×自作EPCによるフルMVNOの運用とその実態」というタイトルで発表しました。

タイトル中の「その実態」がポイントで自作 EPC システムの開発初期を支えたメンバーが徐々に離脱するなか、知識・経験が不足している自分が何に悩み、どんな道筋を立てて運用を引き継いだかを伝えたいと思いました。以下ではその中身を述べていきます。

運用参加初期に思ったこと

親会社であるさくらインターネットから BBSakura Networks に出向してすぐに「さくらのセキュアモバイルコネクト」のモバイルコア部分の運用開発メンバーに加わりました。そして参加して間もない頃に発生した通信障害の対応を通してモバイルシステム特有の運用の難しさを実感しました。

何らかのトラブルにより通信断が継続した場合にはシグナリングストームが発生すること
外的要因（基地局〜モバイルコア間のネットワークのどこかで発生する通信断など）が解消された後でもシグナリングストームによる大量の通信要求を処理しきれないケースがあること

また、フルスクラッチで内製されたシステムであるため運用担当者には以下の認識が必要と感じました。

自力で解決するしかないこと（トラブル発生時に保守業者にお任せといった対応はできない・エスカレーション先は無い）
そのため、通信障害を速やかに収束させるにはシステムに対する深い理解（システム全体を俯瞰して障害原因を特定・各コンポーネントのソースコード把握）が要求される

出向前に在籍していたさくらインターネットの DC 業務および前職のシステム管理業務では、不具合発生時には予め定められた作業手順書に従って対応すること、復旧が困難な場合にはサポート先へエスカレーションすることが原則だったため、自分がこの水準を満たすには相応の時間が必要と判断しました。

そして何ヶ月か経過した後、開発初期からこのシステムを担当しているメンバーが社内異動等により徐々にチームから離れていくことが決定していきました。

自分が主担当として運用していくために何をすべきか

初期メンバーがチームを離脱するまでにある程度の期間が設けられていたため気持ちの準備はできていたものの、各メンバーが通常の業務に追われる日々が続いたため引き継ぎのための時間を十分に確保することは困難な状況でした。そのため、開発初期メンバーと同等の知識経験が無い自分がこれまで実現されていた運用水準を維持向上してくためにはある程度の方針・計画を立てて進めていく必要があると感じました。それをふまえて実践したことが以下になります。

障害発生時の原因絞り込み & 認識の共有ができるための準備

システムを構成するサーバ・ルータの詳細なネットワーク図を作成しました。意識した点として障害箇所とその影響箇所がひと目でわかるよう、すべての構成要素が一枚の図に納まるようにしました。加えて要素間での疎通確認・リモートアクセスが即座にできるよう各要素には IP アドレスの明記を必須としました。

ミドルウェアの統合化 & さらなる整理

開発初期のメンバーといっしょに進めてきたミドルウェアの統合化作業をメンバー離脱後も継続しました。多少の修正を加えれば必要が無くなるミドルウェアは基本外す方向で積極的に置き換えていき、システム全体の構成をシンプルにすることに努め、障害発生時に疑うべき点を減らしていきました。

自動デプロイの導入はあえて採用しなかった

自動デプロイの導入が当初より検討されていましたが、理解が必要な技術が増えること、中途半端な状態で導入した場合の運用リスク（障害発生時、デプロイツールの動作に問題が無かったかを検討する時間が発生するなど）を懸念し、枯れた手段であるコマンドが列挙された手順書によるメンテナンス作業をあえて採用するようにしました。

サービス提供主体側との密な連携

サービス提供主体であるさくらインターネット側のメンバーと役割分担を推進して通信障害が発生した際に原因究明に注力できる体制を設けました。また、障害対応後の振り返りができるよう各役割の連携フローをまとめ、実際に障害が発生した際に用意したフローに従ってお互いが連携できるよう合同の運用訓練を定期開催するようにしました。

取り組んだ結果

稼働率（通信断の状態だった時間の合計割合）が前年度比で改善できたことは素直に嬉しかったです。これまでのメンバーと行ってきた運用のあり方を変えていくことには正直不安がありました。もし開発初期メンバーが継続して運用する体制が維持されていれば、より良い体制になっていたのではないか？と常に感じていたためです。今回の経験を通して自分が主担当として運用するシステムは自信を持って運用できる体制に思い切って切り替えていくことは、システムを引き継ぐ上での有効な手段であると強く感じました。