VM 基盤運用チームの DevOps

Copyright 2020 FUJITSU CLOUD TECHNOLOGIES LIMITED
富士通クラウドテクノロジーズ株式会社
樋口茂幸
VM 基盤運用チームの DevOps

自己紹介
 富士通クラウドテクノロジーズ株式会社 2012年度入社
 樋口茂幸 @YOMOGItanpop
 ニフクラのインフラ運用をやっています
 チームリーダーとしてチーム運営をしています、チーム人数は10人です
 主に VMware NSX の運用をしていて最近 vExpert になりました
2
スクラムガイド
re:Work
よく使うもの・興味分野

今日話すこと
IaaS の裏側の運用の話がテーマです
• 「ニフクラIaaSをこう使うと良い」という話では有りません
VMware 製品で作られて既に運用されている VM 基盤に IaC/CI などの
DevOps の文化を導入していくことがテーマです
3

Copyright 2020 FUJITSU CLOUD TECHNOLOGIES LIMITED 4
運用対象の特徴

運用対象の特徴
 ユーザーがずっと使い続けられるクラウド基盤
• 2010 年から作られた VMware ベースの IaaS システム
• バックエンドのハードウェア・ソフトウェアはアップデートされ改良されたものを使い続けられる
• 12データセンター, 自チームの内部システム用VMが820台存在する
 アプリケーションから変更する管理対象はインフラ
• VMware vCenter などの VM や物理機器のようなコンテナ化できないものが多く含まれる
• 2年に1回は操作停止や仕様変更を伴うバージョンアップが必要になる
5
vCenter4 物理機器 vCenter6 物理機器 vCenter7 物理機器
2010
規模.サービスは
毎年増え続ける
常に最新の
改良された基盤
操作停止を伴う更新操作停止を伴う更新

扱っている基盤の特徴
 ユーザーアプリケーションとインフラのチームが別れている
 自社開発のアプリだけではなくミドルウェアが意図した挙動をするかもテスト対象になる
 こまめに変更したいと言っても1日10回とかではなくて多くて1日1回
6
仮想
ネットワーク
物理
ネットワーク
物理サーバー
ストレージ
仮想サーバー
ストレージ
アプリ
インフラ機器
ユーザーアプリ
インフラ操作
アプリ
監視
モニタリング
ログサービス
インフラ
チーム構成
ここのアップデート時に
要求している仕様を満たしているかの
テストが難しい

いままでの取り組み

Infrastructure as code
 GitLab 上にある Ansible playbook を正とした gitops
 Ansible 内のインベントリ情報がチーム内での信頼できる情報源になっている
 2010年からあった環境を管理下にするために, 2014年頃手順を playbook に再現しすべてのサーバーを一度捨てて再デプロイした(重要)
• ここが既存システム置き換えの最初の壁だが,構成ドリフトがなくなるメリットが大きいので絶対に実施したほうが良い
8
チーム内で決めた
インベントリ情報
チーム外が決めた
インベントリ情報
Ansible playbook
IPAM
ストレージ
環境情報
アプリ設定
ロール
(サーバータイプの情報)
コピー or 参照
構成が統一されているので
開発環境での検証が効果的になり
様々な自動化がしやすくなる

Drift Detection
 以下の2つの目的で構成管理と実際の状態を比較して検知している
• 構成ドリフトの管理
• 手動の変更の実施は「いつから変更されている状態なのかを追跡」,「変更が意図的なものか判断するための変更検
知・通知からの修正」ができれば実施して良いと考えている
• デプロイ判断のトリガ
• 構成情報が更新されている場合に更新する
 Ansible の check mode を GitLab CI で定期実行し検知
• Check mode で変更がわかるような書き方をしている
9
check モード
Ansible playbook 差分検知
に構成ドリフト発生！

CI
 サーバーの組み合わせで発生する問題のテストをする需要がある
 クリーンな仮想化基盤検証環境を作成・起動するための vagrant up, docker run 相当のコマンドが必要なので,ハイパーバイザーとVMを
コピーする仕組みを開発している
 バージョンアップ後の仮想インフラが意図した動作をするかも,一度テスト環境のテンプレートを準備することで簡単になった
10
コミット
テスト
環境作成
テスト
NS
X
VM VM
nested
ESXi
nested
ESXi
nested
ESXi
vC VM VM
テスト環境 VMware vSphere®
nested の環境をクローン
NS
X
VM VM
nested
ESXi
nested
ESXi
nested
ESXi
vC VM VM
テスト環境 VMware vSphere®
ESXi ESXi
テスト
環境
テスト
環境
テスト
環境
new
VM 変更したコードを実行し
vSphere を含む全体の挙動をテスト
利用

CD
 CD は実施していない
 レビュー環境までは見れるがその後は手動
 可能な限りインプレースな設定変更ではなく, CI 実行後の VM を packer などでイメージ化し Blue-green デプロイメ
ントをして immutable なインフラを目指している
 課題になっているもの
• アプリケーションによってスイッチオーバー時に考慮するものが違うのでシステムごとに独自の考慮が必要
• 変更によって Mutable で冗長化されていないサーバーの停止が伴う場合がある(バージョンアップなど)
• (スイッチオーバーでデプロイする仕組みが作れていないレガシーなものも多い)
11
コミット
テスト
環境作成
テストレビュー・マージデプロイ
利用手動
イメージ化

ここまでの評価
できていること
• 再現性のある環境構築
• 継続的インテグレーション
• 稼働環境の状態管理
以下のような課題が残っている
• 自チームで独立してリリース判断できる範囲が狭い
• デプロイ作業が複雑で頻度を上げられない
12

これからの展望

インフラ基盤の抽象化・マイクロサービス化
 現状はインフラを変更するたびにチーム間の協力が必要
• スケジュール調整やプロジェクトの優先度判断で調整コストがかかる
 インフラ基盤を API サーバーで抽象化し,マイクロサービス化する
• 機能追加をしたい場合も調整が不要,開発しながら仕様を決められる
• インフラ機器をバージョンアップと同時に仕様変更があった場合も同様
14
インフラ機器
ワークフローアプリ
インフラ機器
ワークフローアプリ
インフラwrapperアプリ
バージョンアップによる仕様変更バージョンアップによる仕様変更
動作確認と
改修が必要
改修が不要
変更箇所を
緩衝
ユーザー向け開発部門に影響を与えず
エンハンスが可能に

Immutable なサーバーのコンテナ化
 以下の事によりデプロイ速度の向上, CD を簡単に実現できるようにする
• K8s などは blue-green デプロイメントをするためのスイッチオーバーの仕組みが整っている
• 軽量でデプロイ速度が早い
VM から CloudNative 化することのメリットは,「July Tech Festa 2019」で、サイバーエージェントの青山真也氏が行ったセッション『「Kubernetes による Cloud Native な開発」
と「VM 時代の開発」』に多く記載されています
15
Blue Green
独自
の仕組み
k8s LB
Blue Green
セッションなどアクセス
状況を見て影響が少ない
ように切り替えなど
一般的な標準の
方法で切り替え

まとめ

まとめ
既に存在する VM のインフラ基盤運用に DevOps の文化を導入していった
ことの話をしました.
今からシステム設計をする方にはあまりピンとこない話だったかもしれま
せん.
私達もまだ進んでいる途中ですが,もし同じような境遇の方がいたら参考に
なれば嬉しいです.
17

VM 基盤運用チームの DevOps

Recommended

More Related Content

What's hot (20)

Similar to VM 基盤運用チームの DevOps (20)

More from 富士通クラウドテクノロジーズ株式会社 (20)

VM 基盤運用チームの DevOps