CodeZine(コードジン)

特集ページ一覧

【デブサミ2015】20-B-2 レポート
「DevOps」やってみた、そして、気づいたこと・陥ること・見直すところ

  • LINEで送る
  • このエントリーをはてなブックマークに追加
2015/04/08 14:00

 DevOpsは特定の規格ではないため、その解釈、やり方、向かう所など、皆同じではない。とはいえ、それぞれが何かの課題を解決しよう、開発と運用の現場をより良くしようという「思い」から始まっているのは同じだ。本セッションでは、そんな思いからそれぞれが考えたDevOpsを「やってみた」現場から、「気づいたこと」や「陥ってしまったこと」を振り返ると共に、「見直すべきポイント」をIBM DevOpsソリューションを切り口に解説された。

日本アイ・ビー・エム株式会社 IBM システムズ・ソフトウェア事業部 テクニカルセールス統括部
アプリケーションデベロップメント・テクニカルセールス シニアITスペシャリスト 川瀬 敦史氏
日本アイ・ビー・エム株式会社 IBM システムズ・ソフトウェア事業部 テクニカルセールス統括部 アプリケーションデベロップメント・テクニカルセールス シニアITスペシャリスト 川瀬 敦史氏

DevOpsで誰もが考える自動化の前に、標準化が必須

 川瀬氏が考えるDevOpsの概念の基本は「Keep on developing」、「Keep on operating」つまり「創り続け、生かし続ける」ということだ。

 川瀬氏が最初に「DevOpsをやってみたら」の事例として紹介したのは、小さな組織で小さく始めようとしたケースだ。業務はWebサービスの開発で、10人程度のメンバーが開発から運用まで頑張っている。明文化されたルールはなく、暗黙のルールによりどうにか回っていた。

 ただ、ビジネスの拡大、拡張により今のままではいずれ不具合が生じる可能性が高まってきたため、上層部が「DevOpsをしてみよう」と考え、進めることとなった。

「やった」規模は?
「やった」規模は?

 最初にやったことは、テスト、デプロイなどの自動化の検討だ。現場では、これなら簡単で、すぐに効果がありそうだと考えた。それに対し、IT経験の長い上層部から「部分最適ではなく、全体最適をやってみたら」とアドバイスがあった。確かに自動化は即効性があり、効果がある。ただ部分最適だけやっても後々問題が生じないのか、と。きちんと最初に現状を確認しておいて、そこから最終形を描き、自動化や、できていないところをやるべきではということで、全体最適から行おうという流れになった。

 そこでまずやるべきことが二つある。

 一つは、デプロイの仕組みの再構築だ。時代の流れに沿ってオンプレミスからクラウドへ移行し、それを見据えてデプロイの標準化、自動化を行っていく。既存のデプロイプロセスを見直し、全アプリ/全環境共通のデプロイフレームワークを策定する。

 もう一つは、ソフトウェア構成管理の見直しだ。デプロイについて検討するなか、ソース管理が個人管理で、前工程がぐだぐだであるという課題が見えてきた。そこでデプロイフレームワークに対応するソフトウェア構成管理を見直した。ソフトウェア構成管理計画を策定し、デプロイ単位でのファイル管理や、並行開発、作業との関連づけなどを行った。

 そのために導入されたのが「IBM UrbanCode Deploy」になる。デプロイ作業自動化の手助けをしてくれるもので、そこで求められる作業が機能として提供されている。まずデプロイ手順を見える化し、どのコンポーネントにどのバージョンが入っているかを俯瞰できるようにする。テストが終わったら、ドラッグ&ドロップで、次の環境をスケジューリングすることもできる。

 また最近は、複数のモジュール、機能を、時にはサーバーをまたがり、同時進行で開発することも多い。その作業状況と連携し、確認できるアプリ、要件からテストなど先に進めておくケースのため、影響を見える化できるようになっている。さらにアプリケーション環境の作成およびプロビジョニングも可能だ。

 さて今回のケースで「やってみた」結果「陥ったことは以下の通りだ。

  • コスト、期間が想定以上にかかった。
    • 「やる」は人数/規模に正比例しない
  • 思った以上に「やる」ことが多い
  • 小さくても「やる」範囲は広い

 川瀬氏が紹介した二つ目の事例は、継続的インテグレーション(CI)を進めてみた大手企業の話になる。関連組織も大きく、開発部門、運用部門に加えて基盤部門、標準化部門、PMOがある。その中で、標準化部門の施策としてDevOpsを推進することになり、「生産性をあげるにはCIが良いらしい」ということから、まずCIの標準環境を決めて、準備を開始した。

 「やってみた」ことでは、各チームにソース管理用サーバーを用意し、全体では共通ビルド用サーバーを数台用意した。開発部門はサーバーにソースを入れると、自動的にビルドしてくれるという段取りになる。

 ところが、開発チームごとにソース管理のやり方がバラバラだったので、共通のビルドの仕組みにはなかなか乗せられない。そもそもビルドとその前後の標準化ができていなかった。そのためバイナリが肥大化し、ビルド時間が日に日に増加していった。またJavaの管理規約もバラバラなので、ソース管理からのファイル取得、ビルドの手順もバラバラという結果になった。

 さらに「陥ったこと」として、運用部門が用意した共通ビルドサーバーのスペックが足りず、チームごとのビルドサーバーをばらまく結果となってしまった。開発部門はビルド担当者をアサインせざるを得ず、さらに日々のファイル管理がとても面倒になった。

 ここで「気づいたこと」、「見直すべきこと」だが、開発や運用を知らずに標準化をやろうとする人たちは、コスト以外にも気にすべき点があることを知っておくべきだ。将来的な理想像で検討するのではなく、きちんと現状の課題を把握してから「何が必要なのか、どう進めればいいのか」を考えることが重要になる。

 ここでもやはり、ソフトウェア構成管理の見直しが必要になる。ポイントは最終的なビルドを意識したファイル/ディレクトリの構成、個人ビルド、統合ビルドのルール決めだ。

何を自動化するか厳選し、テストは可能なものから先行する

 第3の事例は「Opsから変えて見たら」というアプローチだ。この会社は開発と運用が分離しており、上層部から「ビジネスの変革が必要では」という問題提起がなされた。

 運用部門の課題はコスト削減であり、多くの部門から依頼されている作業をいかに効率化できるかが焦点となる。一方、開発部門に求められているのはリリース時期の死守で、いかにスケジュールを守り、さらに前倒しできるかだ。

 ここでもやはり、最初に考えたのは自動化、特に運用に関わるデプロイの自動化だ。運用部門が主体的に動いて、開発部門が作成した手順書の手作業を自動化し、運用部門の人員ゼロを目指す。これで開発部門も自動化してくれれば、リリース作業をスピードアップできる。

 ここで「気づいたこと」は、アプリ、チームごとのデプロイ手順がバラバラで、標準化、パターン化しにくいということだ。さらに運用部門と開発部門が対話するなかで、色々なギャップが明らかになった。例えば、同じ用語でも両者の意味合いが違うことや、ITIL的な考え方と開発的な考え方の対立が見られた。

 運用側にもスキルフルな人員が多くいるが、コードは読めるにも関わらず開発経験が少ない、という気付きもあった。そのため、何か自動化する仕組みを作ろうとしても、プロジェクトをマネジメントする、要件をまとめるといった観点では無理が生じた。そもそも要員をゼロにするのは無理。デプロイ以外にも様々な運用業務があるからだ。

 そこで「陥ったこと」とは、薔薇色の計画を立て、そこそこの実践をした結果は無残なものということだった。半年の予定が倍の1年かかり、開発部門から要員を追加した結果、コストが3倍になった。しかも効果は限定的。

 そこで、「見直すべきこと」。コードは誰もが書けるわけではない。個人のキャリアや興味が違ってくるので、全員がコードを書けるというのは中々難しい。では、コードを書ける開発部門と運用部門を合体させれば良いのかといえども、その場合はどのように統合するのかが中々難しい。また、開発と運用の両部門がそれぞれ、相手が何をしているのか、理解していないことも多い。

 それぞれの壁をどう乗り越えればいいのだろうか。まず壁が何かを知り、どう壊せばいいかを考える。川瀬氏は「今後、運用環境が変わり、プロセスなどを見直す必要があると考えている」と語った。

 もう一つの観点は、何から始めるのかということだ。すべてを自動化するという方法もあるが、やはり効果があるものを洗い出し、棚卸ししてやっていく必要がある。「80:20」の法則ではないが、川瀬氏の経験では2割程度をきちんと標準化すると、8割ぐらいの効果が出てくる傾向がある。

 川瀬氏は最後にIBMのDevOpsソリューションを紹介した。数多くある中で今回選択したのは「IBM DevOps Solution for Shift Left」。

 このShift Leftは、作ってから受け手に届けるまでの距離/時間を短くするという考え方に基づいている。たとえば最終的に統合する複数のアプリを開発している場合、最終ゴールの統合テストに直進するのではなく、左にシフトして速い時期から可能になった部分の統合テストを先行しておく。3つのアプリの接続数は3だが、9のアプリでは36、12倍になってしまう。

Shift Leftがもたらす利益
Shift Leftがもたらす利益

 Shift Leftのポイントをまとめると以下の3つになる

  • より速い時期での統合&テスト
  • 今の工程よりも一つ前の工程の見直し
  • 前部門による次部門業務の理解

 IBM DevOps Solution for Shift Leftは、DevOpsの実現に寄与すると期待できる。

 川瀬氏は最後に「デブサミ」にかけて以下の4節を披露し、セッションを閉じた。

  • デ:デプロイだけでなく
  • ブ:部分最適でもなく
  • サ:最初から最後までを
  • ミ:皆仲良くやっていきましょう
お問い合わせ

日本アイ・ビー・エム株式会社

〒103-8510 東京都中央区日本橋箱崎町19-21

TEL: 0120-300-426(平日9時30分~17時30分)

IBMのDevOps関連情報

  • LINEで送る
  • このエントリーをはてなブックマークに追加

著者プロフィール

  • CodeZine編集部(コードジンヘンシュウブ)

    CodeZineは、株式会社翔泳社が運営するソフトウェア開発者向けのWebメディアです。「デベロッパーの成長と課題解決に貢献するメディア」をコンセプトに、現場で役立つ最新情報を日々お届けします。

All contents copyright © 2005-2022 Shoeisha Co., Ltd. All rights reserved. ver.1.5