DevOpsの究極は運用グループがなくなること? AppDynamicsの事例にみるDevOps
アプリケーション性能管理のAppDynamicsは、2016年12月8日に都内にてセミナーを開催。このセミナーでは日本での導入事例として動画配信のU-NEXT、KDDIのグループ会社で公衆Wi-Fiサービスを展開するワイヤ・アンド・ワイヤレス(Wi2)、ゴルフ場予約やゴルフ用品ECサイトなどを運営するゴルフダイジェストオンライン(GDO)がパネルディスカッションに参加し、運用監視の概要やいかにシステム開発から運用のサイクルを素早く実行しているのか? などを解説した。
素早いトラブルシューティングで運用グループは不要に?
Wi2の技術運用本部本部長の中野健司氏は、パネルディスカッション前に先立つ個別のセッションで、導入事例としてサービス監視のために導入した概要を紹介し、「これまで数時間から数日かかっていた障害時の原因究明が、数分でできるようになった」とAppDynamics導入の効果を解説した。ここまでは、いわゆる成功事例として製品を売り込みたいAppDynamicsの想定通りだし、会場に集まったパートナー、および見込顧客にとって予想できる展開だった。だが筆者が注目したいのは、この3社がそれぞれ「今は開発グループの中に運用担当が在籍して、運用専門のグループはなくしました」と発言していたことだ。
Wi2の中野氏のプレゼンテーションによれば「従来であれば何かトラブルが発生すると、まずアプリケーションの担当者が呼ばれ、アプリケーション担当者では解決しないと次にインフラ、ネットワークなどの担当者が呼ばれて原因を解明しようとして時間がかかっていた。しかしAppDynamicsを入れてからは、すぐにその原因が分かって対応がとれる」という。今回紹介されたWi2のサービスは全てAWSの上で稼働しているため、オンプレミスのデータセンター環境とは違うとは言え、通常の組織であれば、インフラを担当するエンジニアがアプリケーションエンジニアと協力して原因を突き止めるというのが常識だろう。そのためにトラフィックをキャプチャーしたり、ログをずっと遡って調べたり、少なくとも数日は時間がかかっていたと中野氏は説明した。しかしAppDynamicsのオートディスカバリーとドリルダウンを行う機能によって、複雑に絡み合ったアプリケーション、ミドルウェア、OSなどの構成要素を切り分けて原因を特定できるため、アプリケーションエンジニアであっても即座に原因を突き止めて対応ができるというのだ。
この状況は、主にオンプレミスのサーバー群を使うU-NEXT、GDOでも同様であるという。専任の運用グループはもはや組織上存在せず、それぞれの開発グループにインフラ担当が開発エンジニアと兼務の形で存在するのだという。ここから得られる仮説は、「運用担当の専任グループがなくても通常の運用は可能であり、専門性が要求されるのはトラブルシューティングの時だけではないだろうか」ということだ。
これまでであれば、インフラとなるOS担当、ネットワーク担当、ミドルウェア担当などが縦割り式にソフトウェアを分担し、メンテナンスや最新の情報を社内に共有する役割を担っていたであろうが、オープンソースソフトウェアであれば、アプリケーション開発者であっても情報を獲得することは可能だし、企業向けに窓口となる担当者を特定する必要もないだろう。むしろアプリケーションに最適なインフラは何かを知っているべきは、アプリケーション開発者であると考えるのが自然だ。
そういう意味で「トラブルシューティングの時に専門知識がなくても、ドリルダウンするツールのおかげでトラブルを素早く解消できる」ことで運用専任者が不要になるのは、自明の流れと言えるだろう。LinuxとWindowsという2つのOSプラットフォーム、データベースはSQL ServerとOracle、MySQL、開発言語にはPHPとJavaと多くのソフトウェアを使い分けるGDOにおいてもこの仮説が正しいのであれば、エンタープライズの運用管理という仕事を正常時と障害時の2つに分けて、本当に必要な人的リソースをどう割り当てるべきか? を考えるきっかけになるだろう。
なおGDOのシステム刷新に関しては、2011年にITLeadersにおいて詳細なレポートが掲載されているので参考にしていただきたい。すでにAppDymanicsを利用してから3年以上が経過しているというGDOにとっては、今やAppDynamicsは必須のツールと言っても良いだろう。
勘や経験に頼らない運用管理を実現
ちなみに、AppDynamicsの機能の一つである「監視している対象に異常起きているかどうか」を判定する閾値の設定を行う機能については、3社とも自動に行っているという。ここでも過去の知見をベースに人間がやるよりも、ツールが蓄積したデータを元に行う自動判定でも問題なく運用が回っていることが見て取れる。数台のサーバーならいざしらず、数十台から数百台にスケールアウトするインフラを経験値だけで管理するのは、土台無理があるというものだろう。
このようにパネルディスカッションに参加した3社にとって、DevOpsは素早いアプリ開発と実装、そしてトラブルシューティングの両面で効果を出していると言える。開発からアプローチしていかに実装までも自動化して素早く行うか? という発想ではなく、トラブルシューティングを素早く行うために開発と運用を一つにするというアプローチは、自社をDevOps化するためにツールの選定や開発スタイルの刷新などに迷っている企業にはヒントになるだろう。正常時と異常時の運用コスト比較、トラブルシューティングをいかに素早く行うか? という観点でDevOpsにアプローチすると、意外と最適解に近づけるのでは? そう感じさせられたパネルディスカッションであった。
連載バックナンバー
Think ITメルマガ会員登録受付中
全文検索エンジンによるおすすめ記事
- AppDynamicsのCEO、DevOpsにはビジネス視点が必要と強調
- アプリケーションパフォーマンス管理のAppDynamics、シスコ買収以後も変わらない姿勢を語る
- 「生成AI×オブザーバビリティ」でDevOpsが変わる、企業のデジタル競争力が変わる
- DevOpsのフローとDevOpsの実践に必要な技術
- DevOps全体の監視・調査・障害対応を自動化・効率化 「Splunk Observability Cloud」が DXをスピードアップする
- JFrog Japan主催による、DevOpsの最新事情がわかる開発者向けイベント「DevOps Kaigi ’21」を開催
- 未来志向のデモが披露されたAppDynamicsのカンファレンス
- HPが提唱するDevOps実現の確実な切り口はテストツールの革新から
- de:codeに黒船襲来!? 日本とMicrosoftはDevOpsでどう変わるか
- AIがどのようにIT運用とDevOpsを変えるのか(1)