最終更新日 2019年10月21日
概要
HashiCorp のブログとサイトで、DevOps Defined（定義）に関する２つのドキュメントが公開されました。自分用に翻訳していたのですが、死蔵させておくのも無意味と思い、いつもの通り公開します。私はアプリケーションの開発者寄りではないため、開発寄りのキーワードの翻訳に誤っているところがあれば、ご指摘いただけますと幸いです。
- HashiCorp, DevOps, and the Application Delivery process
- DevOps Defined | HashiCorp
HashiCorp、DevOps、そして、アプリケーション・デリバリ・プロセス
本日の DevOps Defined（DevOps定義）正式発表をとても嬉しく思います。DevOps Defined とは、DevOps の採用によりアプリケーション・デリバリ（application delivery）を速めるためのガイドです。２年前、私たちは Tao of HashiCorp （HashiCorp 道）を公開しました。これは、私たちのツールの背景にある設計原理や哲学について詳しく述べたものです。そして、それ以降は、HashiCorp 道を追求すべく Vault と Nomad など新しいオープンソース・プロジェクトを立ち上げました。これは私たちの技術を共有するという方向づけには、とても有用な財産となりました。
しかしながら、技術とはソフトウェア開発における１つの側面にしかすぎません。ソフトウェアの組織を構成するのは、働く人々、過程（プロセス）、技術です。技術のみに集中するのは簡単ですが、突き詰めていけば、人と過程に対する成功を目指すことになります。つまり、重要なのはソフトウェア組織を支える人々のワークフロー（作業の流れ）と生産性に対する理解です。自らの組織設計にあたっては、ワークフローの強化を通してチームが連携できるようにすべきでしょう。これこそ、私たちにとっての DevOps の本質なのです。
私たちの技術設計思想を HashiCorp 道として定義したように、DevOps Defined では、開発・運用・セキュリティを横断するソフトウェア・チームが生産性をいかに高め、そして、並行して働けるかを定義します。DevOps の目指すところを念頭に置き、私たちは明確な方向性を持ってツールの技術開発します。すなわち、開発・運用・セキュリティの各専門家が生産性をより高めるためのツールを作り上げるのです。
アプリケーション・デリバリの７つの要素、アプリケーション・デリバリを高めるために DevOps 組織をどのように構築するのか、組織内における開発・運用・セキュリティ専門家を強化する技術の使い方について、それぞれを学ぶには DevOps Defined ガイドの全文 をご覧ください。
DevOps Defined（DevOps 定義）
Accelerating the Application Delivery Lifecycle（アプリケーション・デリバリ・ライフサイクルの加速）
課題
DevOps の定義はビジネスによって変化しますが、DevOps におけるツァイトガイスト（zeitgeist、訳者注：ドイツ語の「時代精神」であり、時代背景といった意味合い）とは、ソフトウェア・アプリケーションの出荷（shipping、訳者注；日本でいうところの「ソフトウェアのリリース」）・素早い繰り返し（rapidly iterating）・安全性の問題（securing）を最小限に抑えることです。HashiCorp が DevOps として定義するのは、現代のアプリケーションの必要性、すなわち個人のアジリティ（agility；敏捷性）向上に力を入れるのに関連する、組織のプロセス（過程）なのです。
DevOps is about minimizing the challenges of shipping, rapidly iterating, and securing software applications. （DevOps とはソフトウェア・アプリケーションの出荷・素早い繰り返し・安全性の問題を最小限に抑えること）
DevOps が主に対象とするのは、アプリケーション・デリバリ（delivering applications）に関係する人々であり、開発者、オペレータ、セキュリティ専門家です。３つの役割は持ちつ持たれつの関係であり、アプリケーション配信に寄与するため、密接に連結したツールが必要です。
DevOps とはソフトウェア・デリバリ（配信）のウォーターフォール・モデルから離れる運動（movement、ムーブメント）です。ウォーターフォール・モデルでは、様々なグループを直線上に流れる滝（ウォーターフォール）を通し、ソフトウェア・アプリケーションがデリバリ（配信）されます。開発者は要件を受け取り、アプリケーションを書き、テストを行う品質保証（QA, Quality Assurance）に渡します。開発段階が終われば、アプリケーションはパッケージング（packaging）とユーザ受け入れテスト（user acceptance testing）を行うリリース・チームに渡されます。テストが完了したら、セキュリティ専門家を迎え入れ、コンプライアンス（整合性）とベスト・プラクティスを裏付けます。それから、オペレータがアプリケーションをデプロイしたら、滝（ウォーターフォール）の落下点である監視チームに最終段階として至ります。
伝統的なウォーターフォール・ソフトウェア・デリバリ・モデルの問題点とは、アジリティ（敏捷性）を最大化するのではなく、リスク（危険性）を最小限に抑えることです。ウォーターフォールは個々の自主性を制限し、フィードバック・ループを遅くし、アプリケーションの細やかな変更のたびに多くのチームとチェックポイントを必要とします。
また、DevOps の盛り上がりは、分散型サービスとデータセンタ資源（リソース）を特長づけるハイブリッド・クラウド基盤（インフラ）の台頭にも関係しています。最新のアプリケーションはインターネットに接続しており、ブラウザやモバイル・アプリなどのシン・クライアント（thin client）を備えています。更新を素早く提供できますので、専門的なリスク管理を必要とする「リコール」（recall）はほとんどなくなりました。
DevOps を正しく行えば、ソフトウェア・デリバリ速度を最大化します。配信プロセスのすべてを全体的に眺めれば、よく起こる（traditionally happen）ボトルネックを解消できます。ボトルネックとは、ある処理（プロセス）を担う役割（ロール）に対する負担が高まること。つまり、ソフトウェアは一日のうちで最も遅いチームと同じ速さでしか配信できなくなるのです。
DevOps Defined
Provision, Secure and Run Any Infrastructure For Any Application
あらゆるアプリケーションのインフラ（基盤）でプロビジョニング（供給）、セキュア（安全）、実行を。
組織によってソフトウェア・デリバリ・プロセス（配信手順）の要素が微妙に違います。これは、技術の選択、コンプライアンス要件、あるいはその他の要因によるからです。しかし、木だけではなく森全体を見渡せば、ソフトウェア・配信のライフサイクルには７つの要素があります。
BUILD （構築）
アプリケーションは開発者がコードを書くところから始まります。新しいアプリケーションであれば初期バージョンを書く必要があります。既存のアプリケーションであれば、新しい機能の追加や、バグ修正、性能向上のために、絶え間ないサイクル（繰り返し）があります。この要素は主に開発者が関わるだけでなく、運用チームでも開発者がコードを書くための環境やツールを提供する役割を担うことがあるでしょう。
TEST（テスト）
アプリケーションの作成段階やリリース前には、複数種類のテストを実施します。最も簡単なテストは開発者が行う単体テスト（unit testing）です。そして、統合テスト（integration testing）、受け入れテスト（acceptance testing）、エンドツーエンド・テスト（end-to-end tests）などに階層化できます。これはアプリケーション・デリバリのライフサイクルにおいて重要な部分です。なぜなら、自動的なフィードバックと重要なリスク管理の制御をするからです。開発者の大半のみ関わるだけでなく、専門の QA チームやテスト基盤を管理する運用チームも関わる場合もあるでしょう。
PACKAGE（パッケージ）
アプリケーションを作成し、テストを終えたら、そのアプリケーションをプロダクション（production）用にパッケージ化する必要があります。パッケージ化にあたっては、技術と対象となる環境により、大きく依存する場合があります。たとえば、JBoss の場合は WAR ファイルですし、Kubernetes の場合は Docker コンテナです。アプリケーションの土台（基礎）となるものは、ソースコードを元に、対象の環境上で実行可能なファイルとしてパッケージされています。これらのパッケージは Artifactory （アーティファクトリ、訳者注：Terraform のアーティファクトを置く場所）などのレジストリに格納されています。
PROVISION（プロビジョン）
アプリケーションはどこかしらで実行する必要があります。あらゆる抽象化レイヤの下では、コンピューティング、ストレージ、ネットワークといったリソースの提供が依然として存在します。これらはベアメタルや仮想マシンで直接提供される場合もあれば、PaaS や Lambda-as-a-Service（サービスとしてのラムダ）フレームワークを通して間接的に提供される場合もあります。どちらの場合でも、アプリケーション要件にあわせてプロビジョニングと設定をし、時間の経過とともに更新し、役目を終えれば最終的に廃止する必要があります。通常、運用チームがプロビジョニングを管理（owned）しており、開発者に対して提供します。
SECURE（セキュア）
連結が少なければ少ないほど（as weakest link）、システムの全体的なセキュリティが強力になります。これは、アプリケーション配信プロセスの最初から、セキュリティが関与しているのを意味します。セキュリティ・チームは、開発中にベスト・プラクティスを用いる手助けをし、ネットワーク・トポロジのモデリングを支援し、インフラのプロビジョンに使うプロジェクトの資格情報（credential）を保護します。また、データベースのパスワードや API トークンなど、アプリケーションのデプロイに必要な秘密情報（secret、訳者注：パスワードや秘密鍵などセキュリティ上の重要な情報）に対する権限を与えます。一般的にはセキュリティは専属チームの役割ですが、アプリケーションを提供する他のチームも関与します。
DEPLOY（デプロイ）
デプロイ（展開）とは、基盤となるリソースをプロビジョニング（提供）した状態において、パッケージ化したアプリケーションを取得し、実行するのを意味します。マシンまたは仮想マシンが単一のアプリケーションを実行するよう特化している場合であれば、プロビジョニングとデプロイを密接に連携できます。一方、（プロビジョニングとデプロイが）分かれている場合であれば、スケジューラを用いてマシン上に動的にアプリケーションを置きます。
MONITOR（モニタ）
実行中のアプリケーションに必要なのは、実行が継続し、正常でありつづけるのを監視することです。サービスは障害または劣化したインスタンスからの通信を回避しながら、相互に通信する必要があります。これを担うのがサービス・ディスカバリです（service discovery）。きめ細かい生存確認からログ（logging）とテレメトリ（遠隔測定データ）に至るまで、監視は広範囲に至ります。監視に含まれる担当は、アプリケーションの動作を理解したい開発者と、インフラを管理するオペレータ、アプリケーションの広範囲を維持管理するサイト信頼性チーム（site reliability team）です。
DevOps Delivered （DevOps をもたらす）
Provision, Secure and Run Any Infrastructure For Any Application
あらゆるアプリケーションのインフラ（基盤）でプロビジョニング（供給）、セキュア（安全）、実行を。
高い能力を発揮するチームを設計する（組織する）のは、高性能アプリケーションの設計と似ています。つまり、調整を最小限に（minimal coordination）することです。ソフトウェアの場合はアムダールの法則（Amdahl’s law、計算機システムの並列度を上げたときの性能上限、ウィキペディア ）で最も表されています。そこで、働く個人を「serial execution units」（連続実行ユニット、連続実行単位）と考えれば、同じように人間の生産性も調整（coordination）による支配を受けます。
アプリケーションを配信（デリバリ）するには、７つの要素を飛ばせません。つまり、各ステップの実行に必要な調整を最小限に抑えるのが最優先です。各チームが独立して働けるようになれば、調整を減らせられ、個々の生産性を高められます。すなわち、アプリケーションの配信速度を向上します。これこそが DevOps の中心です。そして、私たちが選択するツールは、これら重要な機能の優先度づけをする必要があります。一貫したプロセスを維持するには、大部分の組織の現実である技術的な不均質に対処するため、これらのツールは技術ではなくワークフローに集中する必要があります。
HashiCorp が提供するのは DevOps を考慮したツール一式であり、アプリケーション配信ライフサイクルの要素間における手動調整を減らすのに重点を置いています。
Vagrant（ベイグラント）
Vagrant は開発者が同僚やオペレータに相談しなくても、自分で開発環境を迅速にセットアップできるようにします。プロダクションのような環境を提供するだけでなく、開発者はより厳しいフィードバック・ループでコードを簡単にテスト可能となります。これは継続的インテグレーション（CI: Continuous Integration）の目標の１つであり、開発者は迅速なフィードバックを受け取ることで、個々の生産性を高められます。
Packer （パッカー）
Packer はアプリケーションをあらゆる環境で実行できるようパッケージするだけのワークフローを提供します。Packer の設定を共有することで、チームを切り離しても、調整をさけることが可能となります。調整に相当するのは Autifactory や Docker Hub のようなレジストリに送る（push）だけです。
Terraform （テラフォーム）
Terraform は共通のワークフローを使い、インフラとアプリケーション・リソースを提供（プロビジョン）するプロダクトです。Terraform はオペレータがプロダクション環境を安全かつ迅速に作成・変更・改善できるようにします。API を宣言的な設定ファイルで体系化しておく（まとめる）ことで、チームメンバ間での共有や、コードのように扱っての編集、レビュー、バージョン管理が可能となります。
Vault （ボルト）
アプリケーション配信サイクルのすべての要素にわたり、秘密情報の管理を集中管理する手法を Vault がもたらします。Vault はアプリケーションとエンドユーザに対し、秘密情報を保管・公開するための高い可用性と安全な手法を提供します。たとえば、暗号化鍵、API トークン、データベースの資格情報です。Vault により、チームはセキュリティ・チームと調整することなく、必要なデータを利用できます。セキュリティ・チームは組織を横断した調整を必要なく、パスワードの変更、資格情報の更新、ポリシー変更が可能です。
Nomad（ノマド）
Nomad はクラスタ・マネージャかつスケジューラです。スケジューラを使えば、組織は懸念事項を解消し、開発者を完全にマシンから引き離せます。そうすることで、開発者は実行したいアプリケーションに集中でき、スケジューラを通してアプリケーションの配置とマシン性能を管理できるようになります。Nomad により、オペレータは多くのマシンに提供（プロビジョン）できるようになります。そして、このマシンは Nomad に対してジョブを送信した開発者とは切り離されているのです。Nomad はアプリケーションを実行可能なマシン上に配置するので、オペレータと開発者が主導で調整しなくても済むようにします。
Consul（コンサル）
Consul は HashiCorp のサービス・ディスカバリと監視ツールです。Consul はアプリケーションの広範囲にわたる可用性を高め、他のアプリケーションから簡単に連携できるようにします。たとえば、ウェブサーバは Consul を使い、上流のデータベースや API サービスを見つけられます。また、Consul はアプリケーション全体の正常性を監視し、正常なインスタンスのみがトラフィックを受け取られるようにします。そして、問題があれば開発者やオペレータに通知します。これはマイクロサービスやサービス指向アーキテクチャとの登場と関連しています。モノリシックなコードを元にする場合の調整を行わなくても、サービス更新の更新は個々のチームが独立して並行して行うことにより、生産性が向上します。
DevOps done right – DevOps を正しく行うことにより、
Allowing Operations, Security and Development teams to work in parallel
（オペレーション、セキュリティ、開発チームが並行して作業できるようになります。）
すべての企業がソフトウェア会社になるにあたり、DevOps モデルを遂行することで、優れたアプリケーションを迅速に提供できるようになります。そして、これを実現すべく、世界中の何十万人ものソフトウェア専門家が HashiCorp DevOps Suite（DevOps ツールの一式）を使っています。
私たちがDevOps の各要素に特別設計したツールを提供することにより、ソフトウェア・サプライ・チェーンにおける様々な関係者（開発、運用、セキュリティ）が、同僚による障害を取り除き、主な関心事に集中できるようになります。つまり、直線的なウォーターフォールの手順（プロセス）を、３つのチームが並列して実行できる手順へと変えるのを意味します。
ワークフローの並行化こそが DevOps の本質なのです。すなわち、アプリケーションをあらゆるインフラ上に供給し、安全に、かつ実行できるのです。
原文
原文にはイラストも掲載されていますので、理解を深めるために是非ご覧ください。
- DevOps Defined | HashiCorp
HashiCorp, DevOps, and the Application Delivery process | HashiCorp – https://www.hashicorp.com/blog/hashicorp-devops-and-the-application-delivery-process.html
関連
- The Tao of HashiCorp | HashiCorp
- The Tao of HashiCorp 日本語参考訳 | Pocketstudio.jp log3