はじめに
はじめまして！こんにちは。
NTTドコモ サービスデザイン部の菱沼です。
普段の業務ではドコモの通信インフラを支えるCiRCUS/MAPSという大規模システムのインフラ開発を担当しています。
今回はいつものアドベントカレンダーとは少し雰囲気を変えて
長年運用されてきたレガシーシステムのインフラ作業自動化のお話をご紹介させていただきます。
ipv6シングルスタックの話に続き、ドコモの通信インフラを支える裏側を技術観点・プロジェクト推進観点織り交ぜつつお話できればと思います！
それでは早速アドベントカレンダー2日目スタートです！
CiRCUS/MAPSってどんなシステム？
本題に入る前に私のチームが担当しているCiRCUS/MAPSって一体どんなシステムかご紹介します。
一言で表現すると、”ドコモの通信インフラを支えるミッションクリティカルシステム”になります。
・・・で結局どんなシステムかってお話ですよね(笑)
もう少し具体的に説明すると、
・SPモードやmoperaといったモバイルインターネットサービスプロバイダ(ISP)としての基本機能の提供
・8200万人のお客様が利用してくださっているdアカウントの認証機能やドコモメールなどの共通機能の提供
これらの大きく2つの役割を担ったシステムです。
なぜ自動化？レガシーシステムが抱える悩み
CiRCUS/MAPSは2003年から運用開始しているシステムです。
約20年弱という長期にわたって運用し続けた結果、2010年ごろのSPモード大規模故障、2012年ごろのスマホユーザの急増により設備規模が大きく増加。現在は約10,000台以上の設備機器で構成されたシステムとなっています。
この機器たちのEOLラッシュがきており、日々マイグレ地獄です（笑）※共感してくれる方いるかな…
これまでは”量”と”品質”の両課題に対応するために、長年システム開発に従事してきたプロフェッショナル集団が人海戦術で何とか対応をしていましたが、結果として開発のスピード・柔軟性が低下、システムのレガシー化につながっています。
そこで、私たちが着目したのがインフラ作業の自動化です。
インフラ作業の自動化とは？
簡単に言うと、人が従来CLIベースで実施していた膨大な設定作業をボタン一つ押すだけで機械が実行してくれるようにすることです。
人が実施していた作業手順書をコード化(＝Infrastructure as Code化)し機械が実施する、そんなイメージ。
自動化することでシステム開発のスピード・柔軟性向上を実現可能です！
自動化のデファクトスタンダード Ansible
CiRCUS/MAPSでは
・RedHat社のAnsible automation platform（以下Ansible）
・Configuration Management Database(以下CMDB)
を導入し、自動化を推進しています。
Ansible とは大規模な IT 自動化を構築して運用するためのエンタープライズ・フレームワーク（※参照 https://www.redhat.com/ja/technologies/management/ansible ）です。
シンプル・パワフル・エージェントレスといったコンセプトを持った製品でChefやPuppetといった構成管理ツールとよく比較されています。
◇Ansibleの特徴
| コンセプト | 詳細 |
|---|---|
| シンプル | Yaml形式での記述のため可読性が高い 様々な製品で利用されている記述方法の学習コストが比較的少ない |
| パワフル | 様々な環境へに導入可能。モジュールが豊富 |
| エージェントレス | エージェントインストールが不要なため既存システムへの導入が容易 |
| 冪等性 | 同じ処理を何回実行しても同じ結果になる |
CLIベースでの作業手順書をAnsiblePlaybookという形でコード化することで、誰が実行しても作業結果が担保されるため、
複数台のサーバをまとめて増設するといった繰り返しの作業時に低コスト・高品質での作業が実現可能です。
なぜAnsibleを採用したか
前述の通り、Ansible以外にもChefやPuppetといった構成管理ツールは存在していました。
Ansibleは自動化のデファクトスタンダードツール、コミュニティ活動も活発という点が一番の決め手になりました。
下記のグラフは過去5年間のGoogleトレンドのグラフです。
グラフから見てもわかるようにAnsibleの検索数が他のツールと比較しても高いことが分かります。
画像引用：Googleトレンド
サイトURL：https://trends.google.co.jp/trends/
実は、Ansibleを導入以前もシェルスクリプトや独自ツールを活用して作業の自動化には取り組んでいました。
しかし、独自ツールのためメンテナスコスト高であったり、自動化範囲が限定的でサイロ化されている、などの課題を抱えていたことからツールのガラパゴス化を回避したい！！という想いがありAnsible採用に至りました。
どんな作業を自動化してる？
まず普段のインフラ開発の領域について話すると、私たちは主にネットワーク～ミドルウェアに対して以下の作業を実施しています。
-
設備の新設・増設
-
物理環境の整備・OS/ミドルウェアインストール
-
ネットワーク設定・各種パラメータ設定
-
新規設備への業務アプリケーションインストール
-
-
設備更改・バージョンアップ
-
ハードウェアの更改
-
OS・ミドルウェアバージョンアップ・パッチ適用
-
業務アプリケーションのポーティング・業務データ移行
-
◇インフラ開発の領域イメージ
業務アプリケーション以外は幅広く見ている形になります～。
続いて、今回構築した自動化実行環境と実際の商用作業の流れについて簡単に紹介します！
私たちのシステムでは検証環境・商用環境それぞれで自動化の実行環境を用意し、
サーバ構築を例にするとざくっり下記の流れで作業を自動化しています。
- 設計者がインフラ関連のパラメータ類をCMDBに格納
※検証・商用各々のCMDBでマスタ管理 - CMDBからインベントリ（ホスト名等）を自動生成
- 生成されたパラメータをPlayBookに連携し、検証環境でリハーサルとしてサーバ構築
- リリース資材類を商用環境に移設
- 商用環境でサーバ構築
イメージは ↓ こんな感じ。
検証と商用の自動化環境統合なども話に上がりましたが、
セキュリティ観点の問題もありましたので今回は別々で環境を用意してます。
以下は具体的に自動化している作業の一例です。
サーバ、ストレージ初期構築関連などさまざまな作業をAnsibleで実行できる形にしています。
◇自動化項目例
|サーバ|ストレージ|ネットワーク|データベース|監視|
|:--|:--|:--|:--|:--|:--|
|BIOS設定|LUN作成|機器状態確認|DBインストール|サーバ監視設定|
|OSインストール|マスキング|コンフィグ設定|パッチ適用|NW監視設定|
|ルーティング設定|ゾーニング|ポート開け閉め|DB初期構築|監視メッセージ設定|
レガシーシステム × 自動化推進 苦労点
ここまでは
- レガシーシステムで自動化を導入した背景
- 採用している技術要素
を簡単にご紹介させていただきました。
ここからは視点を変えてプロジェクトを推進する上での苦労した点を少しだけお話します。
一番の大きな壁は” 変化に対する反対意見 ”でした。
本システムは24H365d ミッションクリティカルなシステムの品質を担保するために長い年月をかけて確立されたプロセス、体制が存在していたこともあり、
自動化推進＝既存とは違う世界を目指すため変化することに対する反対意見がとても多かったです。
検討当初はどうしたらできるのかよりも、変化させることによるリスクばかりが先行してしまい、検討が思うように進みませんでした。
そんな状況を打開できたポイントは以下の3点になります。
1.大小問わない成功体験の繰り返しによる関係者の意識変革、周囲からの信頼取得
2.トップダウン型の組織体制を整備し、自動化の推進力を維持すること。
3.推進力を高めるため、施策立ち上げ時は自動化を目的化してしまう
長年の運用により確立されたプロセス・体制は素晴らしい面もたくさんあるので、全てを否定するのではなく、肯定できる部分は肯定し、変化点については成功体験を積み重ねることで関係者の意識も変えることができると考えています。
おわりに
今回は長年運用されてきたレガシーシステムのインフラ作業の自動化のお話をご紹介させていただきました。
同じような悩みを抱えている方のお役に立てればうれしいです～！
ここまでお読みいただきありがとうございました！