Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

VM 基盤運用チームの DevOps

345 Aufrufe

Veröffentlicht am

2020/07/25 に開催された July Tech Festa 2020 において,富士通クラウドテクノロジーズ株式会社 ネットワークサービス部 樋口 茂幸のスライド

Veröffentlicht in: Ingenieurwesen
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

VM 基盤運用チームの DevOps

  1. 1. Copyright 2020 FUJITSU CLOUD TECHNOLOGIES LIMITED 富士通クラウドテクノロジーズ株式会社 樋口 茂幸 VM 基盤運用チームの DevOps
  2. 2. Copyright 2020 FUJITSU CLOUD TECHNOLOGIES LIMITED 自己紹介  富士通クラウドテクノロジーズ株式会社 2012年度入社  樋口 茂幸 @YOMOGItanpop  ニフクラのインフラ運用をやっています  チームリーダーとしてチーム運営をしています、チーム人数は10人です  主に VMware NSX の運用をしていて最近 vExpert になりました 2 スクラムガイド re:Work よく使うもの・興味分野
  3. 3. Copyright 2020 FUJITSU CLOUD TECHNOLOGIES LIMITED 今日話すこと IaaS の裏側の運用の話がテーマです • 「ニフクラIaaSをこう使うと良い」という話では有りません VMware 製品で作られて既に運用されている VM 基盤に IaC/CI などの DevOps の文化を導入していくことがテーマです 3
  4. 4. Copyright 2020 FUJITSU CLOUD TECHNOLOGIES LIMITED 4 運用対象の特徴
  5. 5. Copyright 2020 FUJITSU CLOUD TECHNOLOGIES LIMITED 運用対象の特徴  ユーザーがずっと使い続けられるクラウド基盤 • 2010 年から作られた VMware ベースの IaaS システム • バックエンドのハードウェア・ソフトウェアはアップデートされ改良されたものを使い続けられる • 12データセンター, 自チームの内部システム用VMが820台存在する  アプリケーションから変更する管理対象はインフラ • VMware vCenter などの VM や物理機器のようなコンテナ化できないものが多く含まれる • 2年に1回は操作停止や仕様変更を伴うバージョンアップが必要になる 5 vCenter4 物理機器 vCenter6 物理機器 vCenter7 物理機器 2010 規模.サービスは 毎年増え続ける 常に最新の 改良された基盤 操作停止を伴う更新 操作停止を伴う更新
  6. 6. Copyright 2020 FUJITSU CLOUD TECHNOLOGIES LIMITED 扱っている基盤の特徴  ユーザーアプリケーションとインフラのチームが別れている  自社開発のアプリだけではなくミドルウェアが意図した挙動をするかもテスト対象になる  こまめに変更したいと言っても1日10回とかではなくて多くて1日1回 6 仮想 ネットワーク 物理 ネットワーク 物理サーバー ストレージ 仮想サーバー ストレージ アプリ インフラ機器 ユーザーアプリ インフラ操作 アプリ 監視 モニタリング ログサービス インフラ チーム構成 ここのアップデート時に 要求している仕様を満たしているかの テストが難しい
  7. 7. Copyright 2020 FUJITSU CLOUD TECHNOLOGIES LIMITED 7 いままでの取り組み
  8. 8. Copyright 2020 FUJITSU CLOUD TECHNOLOGIES LIMITED Infrastructure as code  GitLab 上にある Ansible playbook を正とした gitops  Ansible 内のインベントリ情報がチーム内での信頼できる情報源になっている  2010年からあった環境を管理下にするために, 2014年頃手順を playbook に再現しすべてのサーバーを一度捨てて再デプロイした(重要) • ここが既存システム置き換えの最初の壁だが,構成ドリフトがなくなるメリットが大きいので絶対に実施したほうが良い 8 チーム内で決めた インベントリ情報 チーム外が決めた インベントリ情報 Ansible playbook IPAM ストレージ 環境情報 アプリ設定 ロール (サーバータイプの情報) コピー or 参照 構成が統一されているので 開発環境での検証が効果的になり 様々な自動化がしやすくなる
  9. 9. Copyright 2020 FUJITSU CLOUD TECHNOLOGIES LIMITED Drift Detection  以下の2つの目的で構成管理と実際の状態を比較して検知している • 構成ドリフトの管理 • 手動の変更の実施は「いつから変更されている状態なのかを追跡」,「変更が意図的なものか判断するための変更検 知・通知からの修正」ができれば実施して良いと考えている • デプロイ判断のトリガ • 構成情報が更新されている場合に更新する  Ansible の check mode を GitLab CI で定期実行し検知 • Check mode で変更がわかるような書き方をしている 9 check モード Ansible playbook 差分検知 に構成ドリフト発生!
  10. 10. Copyright 2020 FUJITSU CLOUD TECHNOLOGIES LIMITED 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 を含む全体の挙動をテスト 利用
  11. 11. Copyright 2020 FUJITSU CLOUD TECHNOLOGIES LIMITED CD  CD は実施していない  レビュー環境までは見れるがその後は手動  可能な限りインプレースな設定変更ではなく, CI 実行後の VM を packer などでイメージ化し Blue-green デプロイメ ントをして immutable なインフラを目指している  課題になっているもの • アプリケーションによってスイッチオーバー時に考慮するものが違うのでシステムごとに独自の考慮が必要 • 変更によって Mutable で冗長化されていないサーバーの停止が伴う場合がある(バージョンアップなど) • (スイッチオーバーでデプロイする仕組みが作れていないレガシーなものも多い) 11 コミット テスト 環境作成 テスト レビュー・マージ デプロイ 利用 手動 イメージ化
  12. 12. Copyright 2020 FUJITSU CLOUD TECHNOLOGIES LIMITED ここまでの評価 できていること • 再現性のある環境構築 • 継続的インテグレーション • 稼働環境の状態管理 以下のような課題が残っている • 自チームで独立してリリース判断できる範囲が狭い • デプロイ作業が複雑で頻度を上げられない 12
  13. 13. Copyright 2020 FUJITSU CLOUD TECHNOLOGIES LIMITED 13 これからの展望
  14. 14. Copyright 2020 FUJITSU CLOUD TECHNOLOGIES LIMITED インフラ基盤の抽象化・マイクロサービス化  現状はインフラを変更するたびにチーム間の協力が必要 • スケジュール調整やプロジェクトの優先度判断で調整コストがかかる  インフラ基盤を API サーバーで抽象化し,マイクロサービス化する • 機能追加をしたい場合も 調整が不要,開発しながら仕様を決められる • インフラ機器をバージョンアップと同時に仕様変更があった場合も同様 14 インフラ機器 ワークフローアプリ インフラ機器 ワークフローアプリ インフラwrapperアプリ バージョンアップによる仕様変更 バージョンアップによる仕様変更 動作確認と 改修が必要 改修が不要 変更箇所を 緩衝 ユーザー向け開発部門に影響を与えず エンハンスが可能に
  15. 15. Copyright 2020 FUJITSU CLOUD TECHNOLOGIES LIMITED Immutable なサーバーのコンテナ化  以下の事によりデプロイ速度の向上, CD を簡単に実現できるようにする • K8s などは blue-green デプロイメントをするためのスイッチオーバーの仕組みが整っている • 軽量でデプロイ速度が早い VM から CloudNative 化することのメリットは,「July Tech Festa 2019」で、サイバーエージェントの青山真也氏が行ったセッション『「Kubernetes による Cloud Native な開発」 と「VM 時代の開発」』に多く記載されています 15 Blue Green 独自 の仕組み k8s LB Blue Green セッションなどアクセス 状況を見て影響が少ない ように切り替え など 一般的な標準の 方法で切り替え
  16. 16. Copyright 2020 FUJITSU CLOUD TECHNOLOGIES LIMITED 16 まとめ
  17. 17. Copyright 2020 FUJITSU CLOUD TECHNOLOGIES LIMITED まとめ 既に存在する VM のインフラ基盤運用に DevOps の文化を導入していった ことの話をしました. 今からシステム設計をする方にはあまりピンとこない話だったかもしれま せん. 私達もまだ進んでいる途中ですが,もし同じような境遇の方がいたら参考に なれば嬉しいです. 17
  18. 18. Copyright 2019 FUJITSU CLOUD TECHNOLOGIES LIMITED

×