アプリケーションデベロップメント・テクニカルセールス シニア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のポイントをまとめると以下の3つになる
- より速い時期での統合＆テスト
- 今の工程よりも一つ前の工程の見直し
- 前部門による次部門業務の理解
IBM DevOps Solution for Shift Leftは、DevOpsの実現に寄与すると期待できる。
川瀬氏は最後に「デブサミ」にかけて以下の4節を披露し、セッションを閉じた。
- デ：デプロイだけでなく
- ブ：部分最適でもなく
- サ：最初から最後までを
- ミ：皆仲良くやっていきましょう
