第16回itSMF Japanコンファレンス/EXPO
SCSK講演「体験！イノベーションを加速するDevOpsの能力」～事例編～

DevOpsの事例

では続いて、DevOpsの事例を6つの項目に分けてご紹介していきます。

ビジネス背景

まず、お客様は従業員1000名を超える大手金融企業様でした。
市場の飽和、シェアリングエコノミーによる協議、AI・IoT・モバイル端末などの取り入れに伴い、2017年、デジタル活用を前提とした戦略的なプロジェクトを発足することに。
当時の既存（Brown Field）は、オンプレミスによる大規模な一枚岩のシステムでした。大規模なシステムリリース、グループ会社合併に伴うシステム統合、そのプロジェクトにより人材が枯渇しているという状況だったのです。
そこで顧客IT変革リーダーから、SCSKのアーキテクト3名が指名され、クラウドを前提とした新たなアーキテクチャ構想がスタートしました。

組織

立ち上げ時は、顧客IT変革リーダーと、SCSKの3名のアーキテクトを中心に、アジャイル開発、DevOpsの導入に加え、UI/UX手法、クラウドファーストの構想を検討しました。
現在は小規模なビジネス単位で、顧客営業担当を含むアジャイルチームを組成しています。運用はプラットフォームチームから構成し、オートメーションを前提としたクラウドインフラストラクチャーの提供、フィードバックの仕組みを提供しています。
顧客の同一フロアで全関係者が働いていることも、ムダの削減、共通理解に大きく寄与しているでしょう。

この組織を構築できた理由をひとつ挙げるならば、それは顧客のリーダーの存在です。
変革意識、営業担当からの信頼の厚さ、行動力、またSCSK Dev担当アジャイルチーム3名が主軸のチーム編成という戦略性にあると考えています。もちろんそのリーダーを、高い社内調整力をもって支えた顧客マネージャーの存在もあります。
開発当初、SCSK側にジレンマもありました。新しい取り組みにチャレンジしたいというエンジニアの思いと、優秀なアーキテクト3名をロックインされることへの組織の抵抗です。結果的に当社のビジネスとして30名以上の要員が参画するまでに成長し、当社の先進事例として発表できるところまでプレゼンスが向上しています。

アジャイル開発

ウォーターフォールは大バッチで、半年～1、2年かけて開発するスタイルです。初期に要件を確定し、後工程での変更は影響が大きいため変更を許容しません。そのためプロジェクトマネージャーによる高度な管理が必要になります。
これに対しアジャイル開発は、成果を視察し継続的な繰り返しのリズム、小バッチの成果を累積していく手法。1～2週間のサイクルで優先度の高い要件から開発を進め、決められない要件は後回しにします。途中変更を受け入れ、プロジェクトマネージャーによる管理も存在しないため、自己組織化が進んでいきます。まさにリーンの小バッチ化とプルの原則です。

自動化―採用技術

本事例では、まず継続的インテグレーション（CI）と継続的デリバリー（CD）を導入しました。使用したのは、アトラシアン社が提供する「Bitbucket Bamboo」で、これによりビルド、自動テスト、デプロイ（リソース調達、起動・停止を含む）をタスク化します。
IaC（環境）では「AWS CloudFormation」「ANSIBLE」を採用。インフラストラクチャーの構築を自動化し、サービスのほとんどの環境をCodeで定義できました。
IaC（コンテナ）には、それぞれの製品にあらかじめIaCのための機能が備わっている「docker」を採用しました。

自動化─マイクロサービス

マイクロサービスは、バッチサイズを小さくするための設計アプローチです。ポイントは、独立して稼働する小規模な複数サービスで構成されていること。サービス間はネットワークを経由し、API により連携、要するに疎結合ということです。
小規模なチームで開発して、個別にリリースできる...そんなサービスのサイズが理想ですから、SOAサービス手法アーキテクチャも同様の考え方で、ビジネスプロセス・ルールの簡易化、サービスの独立稼働、高難易度の設計技術要素に注目しています。
これに対してマイクロサービスは、バッチサイズを小さくしてひとつの役割に集中するので、他に影響を与えることなくリリースに向かうことができます。

自動化─イミュータブルインフラストラクチャ

イミュータブルインフラストラクチャとは、「環境の使い捨て」ということ。
例えば新しいバージョンのプリケーションをリリースする場合は、環境に新たに作り、古い環境を破棄していました。従来型のアプリケーションデプロイでは、OSミドルウェアのパッチ適用など、アップデートにあわせて環境を育てていました。
そこでIaCを前提とした"使い捨てのシンプルな構成"にすることで、マニュアル動作での上書きによる不具合を抑止することができます。本番環境を調達しやすいこと、Codeによるインフラ構築を促進することなどもメリットでしょう。
このイミュータブルインフラストラクチャを促進する技術がコンテナです。本事例では「docker」を採用しました。デプロイの単位はアプリケーションではなく dockerコンテナで、AWS のローリングアップデート機能により、コンテナのプロビジョニングを制御し、無停止リリースも実現しています。

自動化─低リスクリリース

リリースの手法として、「青-緑（ブルーグリーン）デプロイパターン」と「カナリアリリースパターン」があります。どちらも新しいバージョンのリリースをあらかじめ準備しておき、フィードバックを入れた上で本番化する手法です。
まず「青-緑（ブルーグリーン）デプロイパターン」は、現バージョンとは別に、公開するエンドポイントをあらかじめ準備した新環境に切り替えることにより、無停止リリースを行います。例えば、本番環境とステージ環境を交互に切り替えるイメージです。
「カナリアリリースパターン」は、現バージョンとは別に新しい環境を一部のユーザーのみにリリースし、全体のトラフィックの一部を新バージョンに振り分けることで、リリース後の不具合、影響を限定的にする方法です。

自動化─ステートレスなインスタンス（セッション外部化）

イミュータブルインフラストラクチャ、低リスクリリースを実現するためには、セッションの振り分けが必要です。
ローカルキャッシュでは、稼働するマシンのメモリにセッション情報を送るため、ユーザーアクセスを振り分けることができません。これでは環境の入れ替えが難しく、これがいわゆるスティッキーセッションとなります。
そこで、セッションが外部のインメモリデータストアに保存されるようにします。本事例で採用したのは「Amazon Elastic Cache」で、メモリの同期というミドルウェアの機能も存在しています。例えば JBossであればインフィニスパンなどもありますが、リリースが複雑になるため、セッションの外部化を採用しています。

フィードバック─リアルタイム通知

フィードバックはまだまだ発展途上ですが、実装済みの仕組みについて少しご紹介していきたいと思います。
本事例では、メールではなくチャット、Slackによるコミュニケーションの場を採用しました。
さらに「Jira Software」や「Bitbucket Bamboo」などのアトラシアン製品のツールと連携し、デプロイパイプラインの活動状況をリアルタイムでフィードバックします。障害通知は「CloudWatch」に集約されたメトリクスから運用担当者のSNSに障害アラート通知を行います。
また夜間などの対応も考えて、「Amazon Connect」を活用した、電話による音声通知も実装します。

フィードバック─セーリングアスピリティの監視活動の可視化

モニタリングでは、セキュリティの監視活動の可視化、セーリングアスピリティの監視活動の可視化、システムおよびユーザー活動状況の可視化、ユーザーへのAWS課金状況の可視化などについて行っています。これらは「Amazon Quick Sight」「Amazon Elasticsearch Service」を利用しています。

フィードバック─モニタリング（セキュリティ）

WAFの活動状況を可視化し、ブロックされたアクセスの傾向を把握します。事例では、「Amazon Quick Sight」を利用しています。

フィードバック─モニタリング（ユーザー活動状況）

このフィードバックが今後、重要になると考えています。インフラストラクチャーのリソース状況の可視化とユーザーのアクセス数、アクティブユーザー数を可視化しています。事例では、「Amazon Elasticsearch Service」を利用しています。

フィードバック─モニタリング（課金状況）

タグ付けによりAWSの課金情報をチーム単位に可視化すると共に、次月の課金の予測値を可視化しています。事例では、「Amazon Quick Sight」を利用しています。

承認プロセス

現代の企業のほとんどは「変更承認重視」のスタイルなのではないでしょうか。

変更承認重視とは、管理職、ステークホルダーによる権威承認を受ける（現状、監査にて必要な活動）こと。問題（現場）から遠く、品質に寄与しない可能性があったり、承認が後工程によりフィードバックが遅延したり、承認待ちによりリードタイムが延びたり...というデメリットが生じます。ITIL を導入している企業様でも変更管理プロセスが存在します。
現場にいない、忙しい役職者の承認を得るというボトルネックが発生し、リードタイムが長期化していませんか？また、現場にない承認者が、すべてを把握し明確な根拠をもって承認することは困難なもの。例えば、信頼する部下が「大丈夫と言っているから大丈夫だろう」といった曖昧なケースもあります。
事例の企業様にも変更承認プロセスが必要でしたので、DevOpsは上流での「ピアレビュー」を重視することにしました。問題を把握しているチームメンバーに精査してもらうことが、より早く問題を発見し、品質に寄与できるという考え方です。インシデント、問題管理、変更管理、要求実現などのプロセスをJira Softwareで実装しています。
また、BambooのデプロイプランとJira Softwareの連動も行っています。対象のリリースバージョンの変更チケットをBamboo側で作成し、Jira Software側で承認することによって、Bambooのデプロイ権限を付与するというような仕組みも作り込んでいます。
このように運用におけるシームレスな仕組みを提供し、リードタイムの短縮とムダの削減にアプローチします。現在は一部のチームにリリースし試験運用開始しているところです。

セッションのまとめ

DevOpsは未開拓（Green Field）側の管理システムですが、既存（Brown Field）側で事例を作ることができたのであれば、さらなる適応をすべきと考えています。
ただしDevOpsの組織を作ることは簡単ではありません。今まで専門領域で分業していた組織も、小規模な多方向な組織に変革する必要があるからです。それでも、未開拓（Green Field）側で文化と組織を作り、徐々に広げていくことができれば、既存（Brown Field）側の技術的負債はDevOpsによって解消できると考えています。現に、事例で紹介したお客様は既存（Brown Field）側へ適応するための土壌が調整しつつあると考えています。
ひとつ注意したいことは、開発側だけのアジャイルは失敗する可能性が高いということです。身近な失敗事例としては、価値を提示せず、タスクをバックボーン化しただけの怠惰なアジャイルプロセスなど。ウォーターフォール以上に密結合やブラックボックスとなり悪い結果をもたらします。受けが良いのは、見た目のフィードバックが得られる最初だけです。
ユーザー側が近いと見てアジャイルチームに参加していないか、運用側のエンジニアが不在でリリースを前提としたアーティファクチャーが設計していないか。リーンの原則が理解されておらず、文化と組織が形成されていない、などが外から見た状況です。アジャイルだけを導入するのではなく、DevOpsを導入すべきだ私は考えます。コモディティ化によりアーキテクト不在の危険なアジャイル開発もいくつか目にしているので気をつけていただきたいです。
最後に、未だ発展途上である小規模な組織ではありますが、お客様の視点で真に内製化を支援できる組織でありたいというのが我々の目標です。この取り組みが部門レベルの標準的な取り組みとなるよう、活動を今後も広げて参ります。