Agile&DevOps推進担当の川上です。今回は開発ツールの話の中でも、アジャイル開発を支えるCIツールについて、もう少し詳細にお話したいと思います。
クラウド時代に手作業？？
KDDI Business IDのシステムは60台以上の仮想サーバで構築されています。これらのサーバに、プログラムのリソースを手作業で配信することを想定してください。
0.sshでログイン
1.資産ファイルを配置
2.アプリケーションサーバを再起動
3.プロセスの稼動状況を確認
当然、商用サービスとして稼動している状況なので、正しいファイルか、正しい配置場所かどうかを確認するといった作業も含みます。1サーバ20分で作業が完了するとしても、60台だとして単純計算で1200分、平行作業で3チーム実施するとしても、400分（6時間以上）必要です。KDDIの社内では、作業はペアで実施しますので、3チーム×2名=6名が必要となります。これでは、商用作業が非常に長時間、高コストなイベントになってしまい、サービスを継続して改善していくという事を実現する上で障害になってしまいます。また、商用作業でサービスを止めるとお客様にご迷惑をおかけし、ましてや手作業によるオペレーションミスなどでサービスを停止させては、信用問題にも発展します。そこで、KDDI Business IDのような常に成長を求められるようなシステム、大量のサーバに同じオペレーションを行うシステムには、自動デプロイの導入をお薦めします。
社会インフラに求められるサービスレベル
KDDIは携帯電話事業をはじめ、様々なサービスを提供しています。特にメジャーな携帯電話事業では、4,000万を超える回線を収容しています。また、それらを支えるサーバや、ネットワーク機器、交換機は全国で数百台、数千台に及びます。通信サービスは、今や電気、水道と同じような社会インフラとして必要なサービスであると考えています。「サーバが止まっていてメールが送信できません。復旧は三日後です」では、ビジネスにもプライベートにも安心してご利用いただけませんよね。社会インフラとなった通信インフラには、当然、高度なサービスレベルを要求され、サービスを支えるシステムの運用にも同じ事が言えます。数百台に及ぶサーバに対してオペレーションを全て手動で行うことは、コストもかかりますし、先ほど述べたサービスレベルを担保することは難しいことです。これまでは、ソフトウェアのアップデート等の作業は、下記の手順を手動で実施していました。
1.旧バージョンのソフトウェアのバックアップ
2.新バージョンソフトウェアをアップロード
3.プロセスを再起動して新しいソフトウェアを起動
4.プロセスの正常動作を確認
勿論コマンドラインで、実施しているので時間もかかりますし、ミスを無くす為のクロスチェックの体制を敷くなど、かなりの労力をかけて実施していました。これらの作業を、お客様への影響を減らす為に夜間に実施していたのです（健康にもあまり良くないですよね）。
※過去に商用作業を手作業で実施していた際、手順書は1作業でA4数十枚になり、百以上のコマンドをコピー＆ペーストするという物でした。KDDI Business IDではこれらの作業をスクリプト化し、CIツールによる自動配布/チェックを実現しています。以前のBlogに記載したBambooにリリーススクリプトを記載し、それらを実行する事で、商用作業のコストとリスクの削減を実現しているのです。
便利であるがゆえに
CIツールを導入/利用する際に、気をつけないといけない事が有ります。当たり前かもしれませんが、「必要な人しか、商用へのデプロイは出来ないようにする」ということです。CIツールの権限管理機能により、そもそも商用環境へのデプロイを行えるアカウントを制限しています。また、デプロイ作業は管理ログを残し、誰が、何時、何の資産をデプロイしたのか追跡できるようにしています。しかし、CIツールは開発に利用しているシステムで、アカウントも開発部門で管理しており、開発部門で、商用環境へデプロイが出来るアカウントを作れてしまいます。そのため、CIツールと商用設備の間のルートに、運用部門が管理しているルーターを設置し、リリース作業の時以外は、運用部門がルートを落としておくという運用を実施しています。これにより、仮に開発部門が間違えて、開発環境ではなく商用環境にデプロイを実施しようとしても、途中のネットワークで止めるというネットワーク上での対策も取っています。
環境マネジメント（違いを把握する）
Bambooでスクリプト化して自動デプロイ、とてもハッピーな事ですが、準備には当然工数がかかります。スクリプトの動作検証をどの環境で実施するか、という点です。当然商用環境と、検証環境では構成そのものの違いや、IPアドレスの違い等、大小さまざまな環境差分が存在します。商用環境と、検証環境でまったく同じ環境を構築するというのはコスト的にも現実的では有りません。
そこで、環境のマネジメントが必要になってきます。検証環境と商用環境の違いを把握し、検証環境で動く物を、商用で動かすには何を行えばよいのか、ということを把握しておかないと、いざ商用作業を行う際に、痛い目を見る訳です。具体的な例としては、OS/ミドルウェア/アプリケーションの設定ファイルをリポジトリで管理し、リリースする環境に応じた設定ファイルを自動的に適用するなどの対応があります。ここでもCIツールが活躍し、環境に適した設定ファイルを読み込むようにします。よく検証環境で使った手順を、商用環境用に変更する際に、変更漏れが発生するという事があります。人の手でやっている場合はゼロにすることは難しいですが、システム化することで、効率的に漏れをなくすことが出来ます。ツールやテクノロジー、テクニックを使って可能な限り手動の作業を減らすことが、コストとリスクを削減することにつながりますが、使う側が人である以上、完璧は有りません。ツールの運用まで含めて、ベストなプラクティスを今後も模索していきたいと思います。
KDDIのアジャイルの取り組みがIT Proに紹介されました。こちらもご覧頂ければ幸いです。
［1］「うちにアジャイルは無理」、既存の社内常識を打ち破る
［2］アジャイルもコーディングも初体験のチームが、内製化を果たすまで
［3］社内技術力が劇的向上、思わぬ不安がマネージャーを襲う