マルチクラウド 担当者コラム

マルチクラウド・開発検証

モダン開発入門シリーズ：第１回目 -ざっくり解説：DevOps-

こんにちは、ディベロッパー担当の波多です。今シリーズはモダンなソフトウェア開発についてご紹介します。第１回目は“DevOps”の概要について解説します。

DevOps迄の背景

2015年に調査会社ガートナーが情報システムをビジネスにおいて「守りのシステム」と「攻めのシステム」の２つに分類して定義しました。特徴をまとめると以下の通りです。

項目 モード1 モード2
ビジネス 守り 攻め
システムタイプ SoR(System of Record)
結果の処理		 SoE(System of Engagement)
結果の創出
目的 社内業務の効率化 顧客とのビジネスに直結
代表例 基幹システム Netflix、Uber、メルカリ
開発手法 ウォーターフォール アジャイル
補足）
上記開発手法に用いられる
日本における顧客との契約形態		 請負契約 準委任契約
要求定義 明確 あいまい
求められる価値 安定性 スピード
リリース迄の期間 数年 2～3週間

モード1はウォーターフォール型のソフトウェア開発でありシステムの安定性が何よりも求められているのに対し、モード2では要望があいまいなところからスタートして変更も柔軟に受け入れるアジャイル開発により２～３週間の短いリリースサイクルでソフトの機能追加や改善をユーザー様の要望に素早く反応します。またモード2ではモード1に比べてAI等の新しいテクノロジの検証と実装が行い易くなっています。

これらの状況によりモード2へのニーズが高まっており、ITエンジニアはそれに対応できるスキルが求められています。

DevOpsとは

モード２を実施するスキルセットとしてDevOpsがあります。耳にした方もいらっしゃるとおもいますが、漠然としていてあまり印象に残りません。それもそのはずで、DevOpsという用語はベンダー間を越えた統一された定義がなくベンダー毎に表現が異なることが関係しているとおもわれます。
但し大筋はそれほどかわりませんので、今回はマイクロソフトの定義を用いて解説します。

マイクロソフトのDevOpsの定義

開発 (Dev) と運用 (Ops) を組み合わせたものである DevOps は、人、プロセス、テクノロジを統合したもので、
お客様に継続的に価値を届けます。

内容を少しずつかみ砕くと、

開発 (Dev) と運用 (Ops) を組み合わせたものである DevOps は・・・

役割が開発担当や運用担当の役割が縦割りだったことにより何かと弊害があったとおもいます。
例えば開発環境と運用環境でのソフトウエアライブラリの違いで開発したアプリが運用環境で動作せず、責任所在の確認や原因究明に時間を消費したことなどです。
DevOpsでは開発担当と運用担当がタッグを組んでお互いに自身のこととしてお互いの技術範囲に知識や関心を持ち一緒に問題や課題の解決するマインドが大切となります。

DevOps は、人、プロセス、テクノロジを統合したもので、・・・

人）
先程述べたように一緒に解決していくマインドで考え方の基本となります。

プロセス）
もちろんマインドだけでなく、開発と運用が連携した実践的なプロセスも欠かせません。

具体的には、
・ソースコードのバージョン管理
・CI/CDパイプライン（ソフトのテストや本番環境への配置の自動化）
・実装したアプリやその機能の監視（障害監視や利活用状況の把握）
・インフラのコード化
（クラウド環境で似たインフラ環境を繰り返し構築する場合、設定を設定画面からの手作業ではなく、設定内容をコードに落として自動実行で行う）
などがあります。
これらは人的ミスの排除の工夫やプロセスの自動化を行い、各プロセスを効率よくスピーディに行います。

テクノロジ）
プロセスを実現するために下支えするテクノロジやツールも必要となります。

プロセスで述べた具体例に照らし合わせると
　　・ソースコードのバージョン管理・・・バージョン管理システム（Git、GitHub等）
　　・CI/CDパイプライン・・・GitHub Actions、Azure Pipeline、AWS CodePipeline 、Jenkins等
　　・実装したアプリやその機能の監視・・・Azure Monitor 、AWS CloudWatch 等
　　・インフラのコード化・・・Terrraform、Ansible、Azure Template、AWS CloudFormation 等

があります。採用されるテクノロジやツールによっては提供ベンダー間の開発競争が著しく旬なものの入れ替わりも激しいです。場合によっては顧客への継続的な価値の提供に大きく影響することもあります。ITエンジニアの方は目に留まった最新情報のさわりだけでもキャッチアップすることをおすすめします。

・・・お客様に継続的に価値を届けます。

お客様に継続的に価値を提供することがDevOpsの目的です。 リリースしたら終わりではなく、むしろリリース後に監視結果やアンケートのフィードバックで得たシステムを評価して次の改善案を練り、次のリリース計画に反映させます。これらのライフサイクル素早く回すことで継続したアプリやサービスの改善を行います。それによって顧客に価値を提供します。

今回はDevOpsの概要についてざっと解説しました。
最初はなかなかイメージが掴みにくいですが、DevOpsへの入口へお連れできたのであれば幸いです。

補足）

DevOpsについての理解を知るためのおすすめ本

数字でみるDevOpsの効果

DORA(DevOps Research & Assesment) の2019年のレポートによるDevOpsの活動を４つのパフォーマンス指標をDevOpsが充分できている団体：エリートパフォーマーとそれ程できていない団体：ローパフォーマーと比較しているデータです。
※詳細　DORAのリンク先下段にあるドキュメント：2019 Sate of DevOps Report をダウンロードしてご覧ください。尚、ダウンロードされるドキュメントは日本語です。

■指標の説明:

観点 パフォーマンス指標 詳細
スループット デプロイ頻度 担当している主要アプリケーションまたはサービスについて、どれくらいの頻度でコードを本番環境にデプロイまたはエンドユーザーにリリースしているか。
変更のリードタイム 担当している主要アプリケーションまたはサービスについて、変更のリードタイムはどれくらいか（コードがコミットされてから本番環境で正常に実行されるまでどれくらい時間がかかるか）。
安定性 サービス復元時間 担当している主要アプリケーションまたはサービスについて、ユーザー に影響を与えるサービスインシデントまたは不具合（予定外の停止や サービス障害など）が発生したときに、サービスの復元に通常どれくらいの時間がかかるか。
変更失敗率 担当している主要アプリケーションまたはサービスについて、本番環境に変更を加えた、またはユーザーへのリリースを実施した結果、サービ スが低下し（たとえば、サービス障害やサービス停止が発生した）、その後修正（ホットフィックス、ロールバック、フィックス フォワード、パッチなど）行う必要が生じた割合はどれくらいか。

■効果比較:

DevOpsが充分できている団体：エリートパフォーマーと
それ程できていない団体：ローパフォーマーとの比較


コードのデプロイ頻度
エリートパフォーマー　1日に複数回
ローパフォーマー　1カ月に1回～半年に1回
エリートパフォーマーの方が
208倍多い

コミットからデプロイまでのリードタイム
エリートパフォーマー　1日未満
ローパフォーマー　1カ月～半年
エリートパフォーマーの方が
106倍速い

インシデントからの復元時間
エリートパフォーマー　1時間未満
ローパフォーマー　1週間～1カ月
エリートパフォーマーの方が
2,604倍速い
変更失敗（変更が失敗する可能性）
エリートパフォーマー　0～15%
ローパフォーマー　46～60％
エリートパフォーマーの方が
7倍低い

マルチクラウドの記事