【夏サミ2013】C1セッションレポート
4つの視点から読み解くDevOpsにおける改善活動のポイント

課題

　では次に、開発側と運用側の課題を見ていく。

Service Assurance

　例えば本番環境で不具合があった場合、原因がすぐに特定できないと、開発側と運用側に不信感が生じる可能性がある。問題が生じているのはアプリではなく、インフラの可能性があるからだ。どうやらアプリに問題があると分かったら、今度は不具合の再現に時間がかかる。そうすると早く修正してほしい運用側に不満がたまる。

Application Delivery

　アプリケーションがリリースされる際、開発側はすぐにでも実行して欲しいが、運用側は決まっているスケジュール通りにやりたい。お互いの時間軸が違う。またリリース前のテストでは、開発側のテスト環境と本番環境に違いがあれば、信頼性には限界がある。

Service＆Portfolio Management

　開発側からの本番環境の設定情報などの問い合わせに対し、何度も同じような質問を受ける運用側は不満に思っている。

Secure

　開発側は、本番環境にログオンして調べたい。しかし本番環境へのアクセス制限が多すぎ、許されない。

解決策

　西野氏は、これらの両者にうずまく不満を解消するため、以下の解決策を提案した。

Service Assurance

　開発と運用では、使っている環境もツールも違う。本番環境では、モニタリングで障害を見つけることはできる。その後、本番環境上のツールで原因を特定できれば、開発側は原因追及のため再現する必要がなくなる。

Application Delivery

　まずリリースを無人化することで、時間軸の違いを解消できる。テストでは、仮想化環境で開発側の制約を解消する。

Service＆Portfolio Management

　構成管理データベース（CMDB）などで情報共有していく。

Secure

　本番環境のアクセスに制約が多いのであれば、自動的に特権IDを貸し出すような仕組みを取り入れる。同時にrootで入っても、作業者が特定できる仕組みも必要になる。

サービス仮想化により、テスト環境の制約を解消する

　以上の4視点の解決策の中から、西野氏はService AssuranceとApplication Deliveryについて、より掘り下げて語った。

　まずService Assuranceでの本番環境における不具合原因の特定では、例えばCA Application Performance Managementというツールを使えば、本番環境でアプリケーションの性能の劣化、不具合を見つけることができる。その後、原因がアプリ、インフラ、ネットワークにあるのかも出す。そこでアプリに不具合があると分かれば、「どこのメソッドがディレイしている」というレベルまで見える。

　Application Deliveryにおいて、開発側のテスト環境における制約にはいろいろある。大きいのはアプリケーションの連携先に関する部分だ。仕様書などを元にシナリオを作成してテストするのだが、現実問題として難しさがある。結果、テストできなかった部分で、不具合が発生する。

　そこで有用となるのが、連携先サービスの“ふるまい”仮想化する“サービス仮想化”という新しいテクノロジーだ。ふるまいとは、仮想化した連携先にリクエストを飛ばした際に帰ってくるレスポンスのことで、ポイントは応答時間も再現されている点だ。

　西野氏は「テストをする上で、興味があるのは連携先のハードウェア、ミドルウェア、データベースそのものではなく、相手のふるまい」と指摘する。CAはそこに着目し、CA LISAという製品を2012年10月にリリースした。導入した米国の銀行では、リリースしたアプリケーションに100万トランザクション中18,000の不具合があったのが、200にまで減少している。

　では連携先とのインターフェースの仮想化は、どうやるのか。方法論は2つあり、1つは連携先システムとの間の通信をレコーディングする。リクエストに対する応答を学習し、ふるまいを仮想化する。ただこの方法の場合、トラフィックがないと仮想化できない。

　そこで、連携先がまだ存在しない場合などでは、スクラッチでクイックに仮想サービスを生成することもできるようになっている。例えばWebサービスの場合、WSDLさえあれば、それを読み込んで実際に動く仮想サービスを5分程度で作ることができる。

　最後に西野氏は「サービス仮想化により、従来のテストにあった制約が大幅に解消される。その結果ネガティブ・フィードバックが減り、生産性も向上する。ぜひ4つの視点からDevOps、改善活動を行ってほしい」と述べ、セッションを閉じた。