初めまして。
株式会社スプラシアのSREチームに所属している大西と申します。
弊社内のチーム勉強会で「DevOps/CI/CD」について学ぶ機会があったため、そのアウトプットを含めて共有します。
DevOpsについて
DevOpsとは、開発者（Development）と運用者（Operations）がそれぞれ協力し合いながらシステムの開発・運用を行い、ビジネス価値を高めていくという1つの概念です。
現在、海外を中心にITを絡めたサービスが急速に展開されています。こうした激しい波に適応するには、我々も迅速な対応とサービス展開が必要となります。
従来型の開発手法では、開発者と運用者は各々の担当領域が分かれており、それぞれの役割を担っていました。しかし、この手法では、既存システムの改善や新サービスへの展開が遅くなってしまうため、時代の波に乗ることが難しくなってきています。
今後は開発者と運用者との関係をより密に、かつ手作業をできるだけ自動化させることで、よりスピードを出していくことが求められており、それが「DevOps」という考え方です。
※近年ではAIを中心とした機械学習（Machine Leaning）と運用者（Operations）を絡めた「MLOps」もあります。
DevOpsの3つのメリットについて
DevOpsのメリットは大きく次の3つがあります。
①信頼性の向上
DevOps導入前
テストやリリースは手動で行うため、（特にSIerの場合）以下の手順で実施する必要がありました。
1．テスト仕様書や移行手順書を作成
2．1．を有識者/お客様に承認していただく
3．リリースを含むテスト実施
4．結果報告書を作成し、お客様に品質担保の承認とリリースの許可をいただく
5．実施者と確認者が2人1組体制で本番リリースを実施（1人2役で実施する場合もあります）
自社サービスの場合は必ずしも上記の通りではないと思いますが、これに近しいものは実施する必要があると考えられます。
なぜ、このような手順で実施するのか。
その理由はお客様から「信頼」を得るためです。その「信頼」を得るためには多くの工数が必要でありながらも、例えばリリースを完全に手動で行う場合には「ヒューマンエラーのリスク」は拭いきれません。
DevOps導入後
DevOpsで使用するツールを用いることで、テストは「ある程度」自動化することが可能です。ある程度とは、例えば、プログラムソースのコードレビューや品質管理は自動化することが可能となり、人の手で行うテストは仕様の挙動確認のみでOKとなります。リリースも実行コマンドを1度実行することで、本番リリースに必要な作業を全自動で行うことが可能となります。
DevOps導入時は自動化の設定作業により多少のコストがかかりますが、2回目以降は自動化されるため、ヒューマンエラーのリスクも減少し、信頼性の向上を総合的に低コストで実現することが可能となります。
②生産性の向上
DevOps導入前
ローカルの環境構築手順書やソースの管理はExcel等を用いて管理している人が多かったと思います。そのため、ローカル環境が人によっては（ツールのバージョン違い等で）異なったり、開発したプログラムのソース管理が煩雑になったりと手動管理のデメリットが生じていました。つまり、より密なコミュニケーションがないと開発を進めることが厳しい状況でした。
DevOps導入後
環境構築もコマンド1つで自動的に作成し、ソースもツールで簡単に管理を行うことができるようになります。そのため、社内だけでなく、社外の方とコミュニケーションをとりながらの開発が容易になります。
③開発スピードの向上
DevOps導入前
「スピード＜品質」を重視する傾向があったため、綿密に管理しながら開発するウォーターフォール開発が主流でした。しかし、品質担保を重視するための開発であるため、例えば、1,000万円規模のプロジェクトでは、最低3か月以上は必要とされています。
DevOps導入後
品質はツールで一定以上を担保できるようになったため、「スピード≧品質」にシフトすることができます。これにより、例えば、1,000万円規模のプロジェクトでは、200万円/2週間サイクルでのアジャイル開発が可能となります。ウォーターフォール開発との違いは、サービスのローンチ時期を早めることや方向転換が柔軟に行えることが大きなメリットとなります。
ただし、方向転換を自由にできる分、エンジニアに対する負担も大きくなるため、どちらの開発手法が適しているのかはPMやお客様とよく相談して決定されることをお勧めします。
CI/CD
DevOps導入に必須となるツールが「CI/CD」です。
CIとは、「Continuous Integration（継続的インテグレーション）」の略で、修正されたソースの反映やテストを自動化することを指します。
CDとは、「Continuous Delivery（継続的デリバリー）」の略で、検証環境や本番環境へのリリースを自動化することを指します。
横文字が多く分かりづらいため、最初は、「CI/CD」とは「ある程度の作業に対し、品質を担保しながら自動化されること」と考えていただくと良いかと思います。
以下でCI/CDツールの一部を紹介します。ご興味があれば、公式サイトのリンクを貼っておりますのでご参照ください。
① Jenkins
無料で使用できるCIの代表的なツール。このツールと別のCI/CDツールを組み合わせることで、ツールの自動実行が可能となります。
② Kubernetes
Dockerを代表するコンテナを自動リリース、スケーリング、アプリ・コンテナの運用自動化するためのツール。DevOps環境を構築するときは、Docker＋Kubernetesを用いてアプリ開発することはベターだと考えます。Google社では自社サービスを全てコンテナに乗せて稼働しており、その数は約20億以上とのことです。
※参照：GOOGLE のコンテナ
③ Rancher
Kubernetesを可視化するツール。無くても特に問題はありません。しかし、Kubernetesの管理をもっと便利にできるツールであるため、入れて損のないツールです。
④ Git
プログラムのバージョン管理ツール。このツールを用いることで、開発メンバーの更新履歴やソース差異等を可視化することができます。
⑤ Phabricator
タスク管理ツール。このツールを用いて不具合の管理やGitと組み合わせてソースの管理を行うことができます。
⑥ SonarQube
ソースコードを自動分析/品質を可視化するツール。このツールとJenkinsを組み合わせることで、ソースレビューとソースの品質可視化を自動化することができます。
⑦ クラウドサービス
AWS（amazon）/ GCP（google）/ Azure（microsoft）などが代表的です。クラウド系は利用しているインフラ面を簡単に可視化できるため運用・管理する上で大変価値があります。DevOps環境を構築する際は、クラウドで実施することをお勧めします。
スプラシアのDevOps環境
DevOps環境をイメージしていただくため、弊社のDevOps導入前後を図でお見せします。DevOps導入後はほとんどの作業をツールで対応しています。そのため、導入前と比べ圧倒的に低コストで開発を行えるようになりました。
DevOps導入前
DevOps導入後
【将来展望①】マイクロサービス化
ここからは、弊社の自社サービスの目指す姿と必要なシステム/概念を記載していきます。
まずは、弊社サービスのマイクロサービス化です。マイクロサービス化することで、外部とより連携が可能となり、サービスの可用性を高めていきたいと考えています。
マイクロサービスとは、複数のシステムを通信で疎結合し、1つのサービスとして稼働させることです。
例えば、とあるショッピングサイトは、以下の3つの機能を1つのシステムの中に収めて稼働することでサービスを提供していると仮定します。マイクロサービスとは、この3つの機能をそれぞれ１つのサービスとし、それぞれのサービスに対して例えばHTTP通信で疎結合して、実質同じショッピングサイトとしてサービスを提供することです。
マイクロサービスによるメリットは多くありますが、ここでは3つご紹介します。
① サービスの保守性/可用性の向上
物理サーバを複数に分散することが可能となります。そのため、（根幹機能を除く）一部の機能に障害があっても全体のサービスを停止する必要がなくなります。
また、リリースも1機能だけ実施すればよいため、全体でリリースするコストを抑えることが可能です。
② 拡張性の向上
機能/サービスの追加や削除が容易となります。また、外部サービスとの連携もHTTP通信で容易に可能となります。そのため、自社のサービスの一部を他社のサービスに提供することが容易となります。
③ エンジニアの技術力向上
これはマイクロサービスとは直接的に関係ないですが、エンジニアにとって大きなメリットです。HTTP通信で疎結合しているだけであるため、機能毎に様々な技術を導入することも可能となります。例えば、ログイン機能ではPHP、売買機能ではPythonと異なる言語を用いた開発も可能となります。
マイクロサービスを実現するにはDevOps環境に＋αのツールを導入し、CloudNative化する必要があります。
【将来展望②】CloudNative
CloudＮativeとは、クラウドの利点を活用し、各種ツール・サービスを組み合わせてアプリケーションを構築・実行することを指します。メリットはマイクロサービスで述べたことに追加し、必要なツールはほぼ無料のOSSであるため、費用を抑えて実装することが可能です。
CloudNativeを提唱しているCNCF（Cloud Native Computing Foundation）では、以下のチュートリアルマップを提示しています。
CloudNative tutorial map
※引用元：https://github.com/cncf/landscape/blob/master/README.md#trail-map
上図の通り、CloudNative化するためのステップ数は全10ステップです。ただし、必ずしもすべてのステップを実施する必要はなく、自社のサービスと相談しながら必要なものを選択すれば問題ありません。なお、上記のチュートリアルマップのステップ1～3を完了することでDevOps環境は実装可能です。
しかし、スタートアップやベンチャーを除く多くの日系企業は上記のステップ1にすら到達しておらず、まだまだ自社のサーバを利用している傾向が見受けられます。そのため、世の中のスピードについていけていない企業も多くあると考えられます。
CNCFでは、CloudNativeを実現するためのツールの一覧をサイトで公開しております。大変量があるため、自身で取捨選択する必要があります。
余談ですが、Amazon社はCloudNative化を実現したことで、サービスに対して1時間に1,000回以上リリースを行ったこともあるそうです。
※参照：Amazonは1時間に最大1000回もデプロイする。クラウドネイティブなデプロイとはどういうものか？ AWS re:Invent基調講演（Day2 AM）
最後に
最近、ふくおかフィナンシャルグループが次世代バンキングシステムをパブリッククラウドで構築する計画を発表し、その中核を担う勘定系システムの構築基盤として「Google Cloud Platform」（GCP）を採用するというニュース を拝見しました。銀行の勘定系システムをクラウドで行うのは日本初の試みだそうです。
今後、そういった重要なシステムもクラウドに移行していくのではないかと考えています。そうなってくると、DevOpsやCloudNativeの構築はますます重要となってくると思います。
弊社も時代の波に負けないよう、日々技術力向上を目指してまいります。
参考：
https://proengineer.internous.co.jp/content/columnfeature/13575
