OpenShift Ansbile 活用法アプリケーションライフサイクルからみる導入効果

パイオニア様の導⼊事例に学ぶ
OpenShift x Ansible活⽤法
- アプリケーションライフサイクルからみる導⼊効果
⽇本情報通信株式会社ソリューションビジネス本部
クラウドエバンジェリスト常⽥秀明

ときだひであき
常⽥秀明
⽇本情報通信株式会社
エンジニア
インフラ屋さんから⼤規模なエンプラアプリケー
ション運⽤を経てクラウドの世界へ
コミュニティ活動やエンタープライズ企業へのクラ
ウド化を⽀援
2018

最近業務で取り組んでいること
• 企業内アプリケーションのモダナイゼーション
• マイクロサービスアーキテクチャの適応⽅法
• API化、DB分割の理論、ドメイン駆動
• マイクロサービスのCI/CD含めた管理⼿法
• Delivery Pipelineの最適化
• Istio, Service Discovery , Circuit Breaker などなど
• マルチクラウドの活⽤⽅法
• 利点を活⽤した複数Cloud を利⽤したArchitecture
• ⾼レイテンシ配下におけるマイクロサービス(APIサービス）の活⽤

AI／ディープラーニング
IBM Watson/COREVO/COTOHA
今最も注⽬されているテクノロジー
⾃然⾔語検索／分類／テキスト分析
回答候補出⼒（機械学習）
FAQ／チャットボット
SIソリューション
システム開発における⽣産性の向上させ、
コストの低減、構築期間の短縮化を図ります
Intra-martによる構築
API連携（既存資産の有効利⽤）
顧客料⾦系の簡易フレームワーク提供
最適化提案
セキュリティ
守るべきデータの特性を理解して
ベストな対策をご提案します
セキュリティ侵⼊検知〜分析（SIEM）
データベースの監視／レポーティング
公開ドキュメントに対する情報漏えい対策
マネージドサービス
お客様のビジネスを
継続して⽀援する最適な
サービスを仕⽴てます
遠隔からのシステム
監視・障害⼀次対応
個別ヘルプデスク
ITIL準拠のサービス
基盤専⾨SEによる
技術⽀援提供
⾼性能のインフラ基盤
科学技術計算等の⼤量データへの⾼速処理や
ディープ・ラーニングのワークロードに最適な
基盤
NVIDIA製GPUとNVLink接続、
⾼パフォーマンスUNIXサーバ
圧倒的な速度と⾼可⽤性のFlashストレージ
クラウドサービス
各種サービスの導⼊、クラウド環境構築、
運⽤をトータルでサポートします
NI+Cクラウド Power
IBM Cloud
（旧 Bluemix）国内取扱実績No.1
SASなどの各種SaaS
データ活⽤（予測／分析）
リアルタイムの意思決定⽀援、
予知保全等による設備リソースの最適化
全ての顧客接点における最適なオファリング
（オム⼆チャネル・マーケティング）
IoT分析／故障予測による保守効率化
顧客システム主管/運⽤
オンプレ
クラウド
コールセンター/ヘルプデスク/サービスデスク
営業
⽇本情報通信株式会社のクラウド注⼒ソリューション

本⽇の資料
• 本資料は、パイオニア株式会社様と⽇本情報通信(株）で実施した「スーパー
ルート探索」案件の事例を含んでおります。
• 資料中の記載は、OpenShift x Ansible を⽤いた効果について⼀般的な項⽬も
含まれております。全てがパイオニア様で実施してい構成や体制ではござい
ませんのでご注意ください。

本⽇のお客様の⽬的
• OpenShift（コンテナプラットフォーム）やAnsible（⾃動化）
に興味があり導⼊を検討している
• 具体的な事例の中からメリットを共有し、検討を前にすすめた
い

今⽇のテーマ
アプリケーションのライフサイクル
から⾒る導⼊効果

1. 今世の中でおきていること

企業におけるアプリケーション開発の変化
• 企業が世の中で勝っていくためにITは不可⽋
• 業務≒ITシステムになりITと業務は表裏⼀体
• 安定性が重要視されていたシステムから、変化に強いシステム
へ
• クラウドの普及によるComputeの家畜化（ペットから家畜へ）
• ITモダナイゼーションの波

開発⼿法の変化はプラットフォームへ
• クラウドの普及により、アプリケーション開発の⼿法は⼀変
• コンピュートリソースを効率的に利⽤したリリース⽅式などが登場
• クラウドネイティブアプリケーションの登場
• スタートアップ企業や事業(IT)企業の開発では、開発サイクルが年々
短縮化（デザイン志向、リーン・スタートアップ、アジャイル開発、
DevOps、クラウドプラットフォームの成果）
• 結果としてプラットフォーム（インフラ）⾯でも⾰新が起こる
• コンテナの普及(常に開発・リリースしていくCI/CDに最適）
• IaaSでは難しかった(OpenStack等）オンプレでの実装も容易

ニワトリとタマゴ
• 開発⼿法が先か、プラットフォームが先か
• アジャイルソフトウェア開発により、より迅速に変化に対応した開発
が⾏える様になった
• クラウドコンピュートの普及により、より迅速に変化に対応したコン
ピュートリソースを利⽤できるようになった
• 継続的インテグレーション・継続的デリバリのプラクティスにより、
⼈為的なミスを軽減しつつ何度もリリースが可能となった。
• コンテナの普及により、開発・本番という環境⾯の影響を受けずに安
定して何度もリリースが可能になった。

「価値」の考え⽅の変化
• 従来の価値＝安定性
• クラウド時代の価値＝スピード
• 従来の品質基準＝障害が発⽣しないこと
• ⽬的 :開発要求に答える事（ITIL）
• クラウドの時代の品質基準＝障害が迅速に復旧すること
• ⽬的：ビジネスに貢献する事(DevOps)
• 製品(アプリ）⾃⾝の、品質（機能性、互換性、信頼性、安全性、保
守性）から、利⽤時の品質（有効性、効率性、満⾜性）へ

変化するリリース⽅法
• リリースする成果物は従来のように完全に試験されない
• モノリシックな構造からマイクロサービス化する
• リリースの影響範囲を最⼩限にし迅速に戻せる⽅式の登場
• ブルー／グリーンデプロイメント
• カナリアリリース

よくあるリリース⾵景
• ビジネス
• 1ヶ⽉前にお客様から⾔われた些細な画⾯の誤りがまだ直っていない
• Dev
• 画⾯の影響範囲を調べるのに全てを確認したら1週間かかった
• アジャイルで早く修正開発した成果物を、Opsに渡すためのリリース⼿順書作成や申
請処理などに時間がかかった
• Ops
• 既存の成果物の改修においてリリースに必要な申請書類が届いてないため再度確認。
フロント画⾯あったので開発環境を⽤意して練習した後に本番をリリースする
• 品質
• システムのリリースを⾏う際には品質管理資料、リカバリー⼿順の提出は必須。フ
ロントが最も利⽤されてない⽉曜の早朝1時にリリースを許可する

クラウドネイティブなリリース⾵景
• ビジネス
• お客様から⾔われた些細な画⾯の誤りは翌⽇には直っていた
• Dev
• マイクロサービス化されており影響範囲は最⼩に留められている
• アジャイルで早く修正開発した成果物を本番のリポジトリに移動しOpsに依頼
• Ops
• 成果物は開発環境で試験済みであり本番にそのまま適応可能。
• フロント機能のため1割のユーザに向けてカナリアリリースを実施し本番環境上で試
験を実施する
• 品質
• カナリアリリース後、ユーザ品質に問題がなければいつでも全展開OK

パイオニア様
2. OpenShift導⼊事例のご紹介
「スーパールート探索におけるコンテナ技術の活⽤」

• クラウドのパワーを活かした⾼機能・⾼性能化
• ⾞載器では利⽤不可能な計算リソース、コンテンツを最⼤限に活⽤
パイオニア様事例紹介資料より抜粋

導⼊理由と期待する効果
• 短い開発期間
• ⾞載器のソースコードをできるだけそのまま利⽤する必要がある。開
発環境から本番環境への移⾏期間を短縮しなければならない
• 組込からサーバへの移植リスクおよび開発環境から本番へ移⾏する際のリスクが⼤きいと予想
• アプリケーション開発とインフラ開発の依存性を排除
• アプリケーションの性能要求が⼀般的なミドルウェアと異なるため、事前検討時には不確定要素が多く柔
軟なリソース配分が可能な環境が必要
dockerコンテナの導⼊により、環境構築、および、環境依存性の問題をクリア
OpenShiftのポット定義により、コンテナ実⾏環境毎の詳細なリソース割り当てが可能に

• コスト低減・品質向上
• 従来より軽量なサーバ環境を実現する必要がある
• CPUの利⽤率が⾼いアプリケーションであり、同時実⽤性を⾼めるためには、⼤容量のCPUコアが必要
• サーバリソースを負荷変動に柔軟に対応させる必要がある
• 曜⽇・時間帯に応じてカーナビユーザの利⽤状況がおおきく変動する
dockerコンテナの導⼊により、従来より軽量化を実現
ベアメタルの柔軟性により最適なスペックのマシン調達が可能になり、コスト低減を実現
CPUソケット単位のOpenShiftのライセンス体系×物理ソケット数が明確な
ベアメタルサーバによって、ライセンス費の抑制を実現
OpenShiftのオートスケールを⽤いることで、全⾃動でリソース配分が可能に

• コスト低減・品質向上
• 開発コストはもとより運⽤コストの低減と運⽤品質の向上を実現する
必要がある
• 本番サービスを保守する際には無停⽌運⽤を実現したい。特にシステム停⽌が発⽣する際には深夜対応に
なるためぜひとも実現したい。
• 不具合発⽣時における切り戻しを容易にしたい。特にIaaSのマシンで複数の変更を加えたあとの切り戻し
には時間がかかり不具合発⽣の時間が⻑くなりサービスへの影響が拡⼤してしまうためぜひとも実現した
い
OpenShiftのブルーグリーンデプロイメントにより、無停⽌運⽤、定時内リリースが可能に
Gitリポジトリでのコンテナの管理が実現されており、Gitコマンドで以前のバージョンに切り
戻す事が可能に

導⼊後のDevとOpsが感じたメリット

今⽇のテーマ

3. 事例から学ぶ課題と解決
存在している課題と解決

よくある課題
• アプリケーションのリリース(実際の動作するモジュールを本
番環境で稼働させるまでの処理）では考慮事項が多い
• 考慮事項を守るための管理⼿段が「運⽤（と⾔う名の⼈⼒）」
で担保されているケースが多い
• 担当範囲が縦割りになっており従属的な作業になりがち
• 安定して動いて当然というストレス
• もっとも低負荷の時間帯にリリースが必要という環境

OpenShift/Ansibleが実現すること
• DevチームとOpsチームのやりとりをシステム化
• 開発プロセスを含めたアプリケーションライフサイクルを⽀え
る基盤
• 全てをコード化し品質と再利⽤性を向上させる仕組み
• それらを⾼度なITスキル無しで利⽤可能とするUI/UX
• ビジネスのコンプライアンスを守りつつセルフデプロイを可能
に
• 受け⾒(強制的)な組織から⾃主的な組織へ

パイオニア様で実現した品質改善
1. シンプルなオペレーションによ
る複雑なリリース処理
• 環境は複雑でも操作は簡素化
2. 品質保証するためのシステム的
な⽀え
3. インフラ作業の⾃動化
4. リリース時の品質保証
5. 全員の作業が楽になる

1. シンプルなオペレーション
• 単純な機能変更／追加でも、サーバ・ストレージ・ネットワー
ク等、多岐に渡りそれをミス無く実⾏する必要があった
• リリースにおいてDevチーム、Opsチームは事前に定められた申請書
とリソース(バイナリ)の受け渡しを実施し、Opsチームはその⼿順に
従いオフラインで⼊⼿したリソースを本番環境に展開していた。
• OpenShiftの管理コマンド⼀発でリリースまで完結
• バイナリイメージはDockerfileから都度⽣成（直接fileserver等
を経由した受け渡しの廃⽌）

アプリケーションの本番移⾏
Dev⼯程とOps⼯程は現実的に何らかの情報/資源がやり取りされて動く
仮想/物理サーバ {本番}Any Platform { 開発}
DevからOpsへの贈り物
Deploy Manual
(Document)
UT済みの
モジュール
(Bin/Lib)
明⽂化されな
い何か
?
Code ⼿作業
?

仮想/物理サーバ {本番}Any Platform { 開発}
1. ⼿順の漏れ（⼈為的なミス）
2. リソースの不⼀致（バージョンやモジュールの差よる問題）
1
2
3. 確認の⼿間（作業時間が⻑い、特定の時間のみ実施可能、依存
関係の解消が難しい）
3

OpenShift { 本番}Any Container Platform { 開発}
Code Code
(コンテナ定義)
Code
(環境定義)
Other
Data
2. プログラムを動かすために必要な定義1
固定⼿順

Delivery Pipeline
Source Code
<dev>
重点取組
Unit Test
Build
(Docker)
Deploy
(Docker)
System Test
(Web test tool)
Any Container Platform { 開発}
Source Code
<master>
Build
(OpenShift)
Deploy
(OpenShift)
OpenShift {本番}従来⼿作業で実施しているDeployを
OpenShiftの機能で実施
Dev
Ops

Opsの⼿順が⼤幅に簡素化
ひたすらコマンドと確認事項の羅列
# oc create -f nginx-sample_bc.yml
# oc start-build nginx-sample
関係者全員が楽になり品質も向上
シンプルなコマンド

2. システム的な⽀え
• 開発した製造物を実⾏するだけでなく、アプリケーションを継
続的に維持管理していくためのプラットフォームを定義する
• 単に動くためのものでなく運⽤していくために必要な環境が必
要

アプリケーションライフサイクル
開発⼯程
要件
定義
設計開発テスト
運⽤⼯程
運⽤
管理
性能
管理
維持
運⽤
変更
管理
成果
物
1. 実⾏可能なプログラム
2. プログラムを動かすために必要な資材
1
2
3. 環境に配置するための⼿順3
環境構成
1. 変更のあった環境情報
2. プラットフォームの情報
1
2
Dev
Ops

アプリケーションのビルドからデプロイの流れ(1)
Coding
Unit
Test
Build Deploy Test
開発PC file srv 本番環境
1. アプリケーションの実⾏ファイルの開発1 2. 実⾏環境の構築（従来のIaaSの場合）2
仮想サーバを事前に構築が必要
(VMイメージやバックアップを再利⽤）
COPYCOPY
Deploy Manual
(Document)
この例では、開発チームが①を実施し、運⽤チームが②を実施することを想定しています。

アプリケーションのビルドからデプロイの流れ(2)
Coding
Unit
Test
Build Coding DeployBuild Test
開発PC/Repository Repository 本番環境
1. アプリケーションの実⾏ファイルの開発1 2. 実⾏環境の構築（コンテナ環境）2
都度環境を構築(Docker Build)する
この例では、開発チームが①を実施し、運⽤チームが②を実施することを想定しています。
git clone / git mearge によりコード⽤の
レポジトリを同期する
App Source code
k8s code

従来の成果物
デプロイの成果物の変化
コンテナの時代となりDevで保証出来る範囲がグッと向上
Deploy Manual
(Document)
UT済みの
モジュール
(Bin/Lib)
コンテナ時代の成果物
動作確認ずみ
コンテナイメージ
明⽂化され
ない何か
?
Code
Code Code
(コンテナ定義)
⼿作業

コンテナは素晴らしいがその実⾏環境は複雑になる
• 成果物(コンテナイメージ)を起動するだけ・・・ではない
• 実環境においては、コンテナを複数台の実⾏コンピュート上で
動かすことなど多くのことを考慮する必要がある。
• 時代的な背景の中、業界標準となったコンテナをうまく動かす
ための制御ソフトが必要となる。
• そんな中抜きんでたのが Kubernetes

アプリケーション実⾏環境の⽐較
Host
App App App
Host
App
App App App App
Host
App App App App
Host
Traditional
Infrastructure
Containerized
Infrastructure
Orchestrated Containerized
Infrastructure
network
storage

Aシステム（本番）
Aシステム（開発）
Aシステム（臨時障害チェック)
• Kubernetesは、「環境」をコー
ドで作ることが出来る。1つの
k8s環境の中に任意の設定の環境
を作れる(ネットワーク、スト
レージその他もろもろ）まさに
Infrastructure as a Codeの進化
系のような代物
Kubernetesで出来るようになったこと

開発環境のデプロイ
本番環境のデプロイ
同じプラットフォームを利⽤
全ての環境を「等しく」することが遂に可能になってきた
クラウドネイティブ開発における「本番・開発の⼀致」を実現する。 https://12factor.net/ja/dev-prod-parity

開発環境v1.1-fix
本番環境v1.0
同じプラットフォームを利⽤
様々な環境を「管理」することが出来る状態になってきた。
動いている環境は全て「Code化」されてる
開発環境v2.0β開発環境v1.0
本番環境v1.1
環境⾃体を、kubernetes の環境定義ファイルで管理します。また環境定義ファイル⾃体も git 管理することでバージョン管理を⾏うことが出来ます。

アプリケーションライフサイクル
開発⼯程
要件
定義
設計開発テスト
運⽤⼯程
運⽤
管理
性能
管理
維持
運⽤
変更
管理
成果
物
1. 実⾏可能なコンテナイメージ
2. プログラムを動かすために必要な定義
1
2
3. 環境に配置するための⼿順3
環境構成
1. 変更のあったベースコンテナの登録
2. プラットフォームの情報
1
2
Dev
Ops

アプリケーションバイナリを保管具体的には?
ルート検索アプリ
(01機種向け)
(02機種向け)
(03機種向け)
01機種向け-v1.0
01機種向け-v1.1
02機種向け-v1.1
03機種向け-v1.0
03機種向け-v1.1
元となるアプリ
VersionUp
fork
fork
marge
03機種向け-v2.0
独⾃機能追加
fix
Registory Git
コードを保管
本番環境
開発環境
test machine
説明⽤概念図（実際のパイオニア様構成とは異なります）

コンテナ運⽤の課題とOpenShiftの利点
開発ビルドデプロイ管理
• OpenShitは、DevとOpsがKubernetsをより簡
単に（意識すること無く）利⽤することが出来
る機能を提供
• 例えば、環境のテンプレート化、Deployや管
理をするためのアカウントの管理、Codeから
環境作成までの簡略化など

OpenShiftはk8sをPaaSにする
環境に依存した事前定義済みの実⾏コンテナ
必要におうじて適切な「元」を利⽤
環境に依存した事前定義済みの環境定義
必要におうじて適切な「元」を利⽤
OpenShiftのコマンドで簡単にデプロイ
コード
Kubernetesを理解する必要はない

3.インフラ作業の⾃動化
• アプリケーションのライフサイクルの最適化から導き出される
⾃動化ポイントの抽出
• Value Stream Mapping (VSM) などの⼿法⽤いて現状のボトルネッ
クを洗い出しリリースまでの作業を阻害する個所を取り除く
VSMとは、バリュー・ストリーム・マップの略。リーン⽣産⽅式やリーンソフトウェ
ア開発において、⽣産や物流、ソフトウェア開発などの⼯程を改善する際に、現状を
把握し将来のあるべき姿を明確にするために作成されるプロセス図

⾃動化を実装するための道具 (Ansible)
プラットフォーム
1. 構成している計算ノードの追加処理1
1. 構成しているノードの故障対応2
1. コンテナイメージの作成の⾃動化1
1. バージョンアップの⾃動化2
1. 定形作業の⾃動化1
1. チーム間での⼿順の共有2
(1) インフラ側の構築作業 (2) 開発側の構築作業 (3) 運⽤側の定形作業

4. リリース時の品質保証
• 本番、開発を分離しない実⾏環境の提供
• 開発環境における成果物の適切な利⽤
• 環境差異からくる問題の根本解決
• 柔軟なリソースを有効活⽤したリリース⼿法
• Canary release
• Blue-green Deployment

Canary release
検索アプリ
03機種向け-v2.0
検索アプリ
03機種向け-v1.0
LB
90% traffice 10% traffice
現⾏システム新規リリース
http://carnavigation.io

Blue-green Deployment
検索アプリ
03機種向け-v2.0
検索アプリ
03機種向け-v1.0
LB
100% traffice 0% traffice
検索アプリ
03機種向け-v2.0
検索アプリ
03機種向け-v1.0
LB
100%traffice 0% traffice
http://carnavigation.io http://carnavigation.io

まとめ
• ビジネススピードの加速は、開発と運⽤に変化をもたらした
• アジャイル開発、リーン・スタートアップと⾔った⼿法で製造されたアプ
リケーションをより効率的に活かすためDevOpsやプラットフォームであ
るクラウドがより重要に（⽬的はコストからスピードへ）
• OpenShift/Ansibleは、そういった要件に応えることが出来るプラット
フォームである(k8sをPaaSとして利⽤することで⾼速開発が可能に）
• そしてクラウドネイティブなプラットフォームを採⽤することが逆説的に
DevOpsの⼟壌を形成することにもつながる。
• DevとOpsの協調がより価値を⾼めることにつながる

OpenShift ♥ DevOps

今⽇話せていない範囲
これから導⼊を⾏う際に知ってほしいこと
• クラウドのIaaSとOpenShiftの組み合わせはすごく安定
• 導⼊後半年はほぼ障害ゼロ
• その後も多少の修正パッチはあれど問題はほぼゼロ
• 迅速な機能の実現は⼀歩づつ
• kubernnetsの環境上で徐々に⽅式を変更していく事が可能
• できる範囲から積み上げていく
• 無理に最初からしなくても⼈も(DevOps)もシステム(k8s,OpenShift)
も成⻑していく事が可能（安定しているからこそ安⼼して使える）

OpenShift Ansbile 活用法アプリケーションライフサイクルからみる導入効果

OpenShift Ansbile 活用法アプリケーションライフサイクルからみる導入効果

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to OpenShift Ansbile 活用法アプリケーションライフサイクルからみる導入効果

Similar to OpenShift Ansbile 活用法アプリケーションライフサイクルからみる導入効果 (20)

More from Hideaki Tokida

More from Hideaki Tokida (20)

Recently uploaded

Recently uploaded (16)