ここから始めるDevOps 実行インフラ編

DevOpsを始めるにあたって実行インフラの観点から学ぶべきポイントを紹介します。

Transcript

1. ここから始めるDevOps
   ⽇本仮想化技術株式会社
   ⽥中 智明 ttanaka@VirtualTech.jp
   2023/03/15
   1
   実⾏インフラ編
   

   View Slide

2. 発表者について
   • ⽥中 智明
   • VTJ 技術部所属
   • おしごと
   • DevOps案件
   • Terraformのコード
   • 技術ブログ執筆
   • かんたんDevOpsの仕組み作り
   • Software Design 3⽉号の特
   集記事に執筆しました！
   2
   

   View Slide

3. 実⾏インフラとは
   • アプリケーションを実⾏する環境
   • 環境を構築、運⽤、保守するめのツールや⼿法
   • 環境を構築、保守するためのIaC
   • 実⾏環境としてコンテナとKubernetes
   3
   

   View Slide

4. 環境を構築、保守するためのIaC
   • IaCはInfrastructure as Codeの略
   • インフラの構成をコード化し、IaCツールを使って構築
   • 構築⼿順はコード化されているため構築⼿順書を削減
   • ⼈間の⼿を介さないことでヒューマンエラーの削減
   • 何度でも同じ環境を構築できるため冪等性を担保
   • 構築はコードを実⾏するだけでよくなり俗⼈化の排除
   4
   

   View Slide

5. 従来の構築
   5
   ・それぞれのサーバーにSSHログインして⼿作業で構築
   ・環境の差異は頑張って合わせる
   ・⻑期間運⽤していくと設定や状態が秘伝のタレに
   → スーパーエンジニアしか構築作業ができない
   ミドルウェアのインストール
   OSのアップグレード
   設定の反映
   

   View Slide

6. IaCを利⽤した構築
   6
   ・エンジニアはコードを修正してIaCツールを実⾏するだけ
   ・IaCツールがコードに合わせて環境を構築してくれる
   ・コードを実⾏するだけなので誰でも同じ環境を⽤意できる
   ・コードのメンテナンスをしていればよくなる
   IaCツールが
   コードを実⾏
   ミ
   ド
   ル
   ウ
   ェ
   ア
   の
   イ
   ン
   ス
   ト
   ー
   ル
   設定の反映
   OSのアップグレード
   コードを修正
   

   View Slide

7. コードを実⾏するためのIaCツール
   7
   • Ansible
   • AWS CloudFormation
   • Terraform
   • Chef
   • Puppet
   • etc…
   

   View Slide

8. コードを実⾏するためのIaCツール
   8
   • Ansible
   • AWS CloudFormation
   • Terraform
   • Chef
   • Puppet
   • etc…
   選択肢が豊富でどれを選んだらいいかわからない…
   

   View Slide

9. IaCツールの種類
   9
   • IaCツールは2種類ある
   • 命令型と宣⾔型
   • 命令型はあるべき状態を構築するための「⼿順」を宣⾔
   • 宣⾔型はあるべき「状態」を宣⾔
   

   View Slide

10. 命令型
    10
    ・対象のサーバーはコレとコレとコレ
    ・SSHしてパッケージミラーをアップデート
    ・パッケージはコレがインストールされていなければインストール
    ・設定ファイルはココにおく
    ・…
    

    View Slide

11. 命令型
    11
    • メリット
    • ⼿作業と同じ「⼿順」として宣⾔するので、学習コストは低い
    • 汎⽤的なプログラミング⾔語で宣⾔できることが多く、学習コストが
    • デメリット
    • ⼿順を積み重ねた結果、あるべき状態になっていくので、⼿順の意図
    が読みづらい
    • 実⾏した結果を宣⾔しているわけではないので、冪等性を担保しいづ
    らい
    

    View Slide

12. 命令型
    12
    • 命令型が向いている作業
    • サーバーの中の設定
    • ミドルウェアをインストールしたりOSの設定をしたり、など
    • 命令型ツール
    • Ansible
    • Chef
    • Shellスクリプト
    

    View Slide

13. 宣⾔型
    13
    ・こういう設定で
    ・こういうサーバーが何台
    ・名前はこれ
    ・スペックはNコアのX GBメモリ
    ・…
    

    View Slide

14. 宣⾔型
    14
    • メリット
    • ⼿順を気にする必要がない
    • あるべき状態を宣⾔するだけなので、どういう状態のものができあ
    がってくるか、コードから読み取りやすい
    • 常にあるべき状態に維持されるので、冪等性を担保できる
    • デメリット
    • ツール独⾃の⾔語で宣⾔していくので学習コストが⾼い
    • ツールのバージョンによって書き⽅が違ったりするので、気軽にアッ
    プデートできない
    

    View Slide

15. 宣⾔型
    15
    • 宣⾔型が向いている作業
    • クラウドの設定
    • インスタンスが何台ほしい、など
    • 宣⾔型ツール
    • Terraform
    • Puppet
    

    View Slide

16. 16
    かんたんDevOpsでは「Terraform」を使っています。
    

    View Slide

17. 実⾏環境としてコンテナとKubernetes
    17
    • コンテナ
    • 仮想化技術の⼀種
    • 仮想マシンに⽐べてオーバーヘッドが少ない
    • アプリケーションと、その動作に必要な全てのものをパッケージング
    することで、アプリケーションをどの環境に移動しても実⾏可能に
    

    View Slide

18. 仮想マシン
    18
    Windows
    アプリ
    Linux
    アプリ
    macOS
    アプリ
    物理サーバー
    ハイパーバイザー
    ・OSを問わず起動可能
    ・完全なOSが起動するので、⽴ち上がりに時間がかかる
    ・1つのVMにつき、アプリケーション＋OS分のリソースが消費される
    VM VM VM
    

    View Slide

19. コンテナ
    19
    ランタイム
    ライブラリ
    アプリ
    ランタイム
    ライブラリ
    アプリ
    ランタイム
    ライブラリ
    アプリ
    物理サーバー
    ホストOS
    ・コンテナ間でカーネルを共有、起動が⾼速
    ・プロセスとファイルシステムを分離して別のシステムのように⾒せている
    ・1アプリにつき、アプリ分のリソースしか消費しない、OSは起動していない
    コンテナランタイム
    カーネル
    コンテナ コンテナ
    コンテナ
    

    View Slide

20. コンテナのメリット・デメリット
    • メリット
    • アプリをどの環境に移動しても同じように動作するので移植性が⾼い
    • 完全なOSが起動しているわけではないので、無駄なリソース消費がな
    い、起動が早い
    • 必要なものが全てパッケージングされているので管理が簡単
    • デメリット
    • コンテナ技術の習得、学習コスト
    • ちょっとした修正でもコンテナを作り直す必要がある
    • アプリごとにコンテナ化され運⽤が複雑化しやすい
    20
    

    View Slide

21. 実⾏環境としてコンテナとKubernetes
    21
    • Kubernetes
    • 読み「くばねてぃす」「くばねてす」「くーべねてぃす」
    • 略記は「K8s」（けーえいつ、けーえいとえす、けーはちえす）
    • コンテナオーケストレーションツール
    • YAMLフォーマットのコードで宣⾔的にコンテナ運⽤ができる
    

    View Slide

22. 従来の運⽤
    22
    ・それぞれのサーバーで1つのアプリを運⽤
    ・アプリ間で空きリソースをシェアできない
    ・アプリに異常がないか監視、必要であれば復旧
    ・対象のサーバーが増えると運⽤がカオスに
    rsyncやscpでアプリケーションを転送
    ランタイムやミドルウェアをインストール
    運⽤・監視
    

    View Slide

23. K8sを利⽤した運⽤
    23
    ・エンジニアはコンテナのあるべき状態を宣⾔
    ・コンテナの監視や運⽤はK8sにお任せ
    ・アプリが利⽤不可になったら、決められた⼿順で⾃動復旧
    ・アプリのことはK8sに任せて、K8sの運⽤のみを考えればOK
    Kubernetes
    アプリ1
    アプリ2
    アプリ3
    コンテナの状態を宣⾔
    

    View Slide

24. K8sのメリット・デメリット
    • メリット
    • 複雑化したコンテナの運⽤・保守をK8sに任せられる
    • アプリケーションの無停⽌デプロイ、障害の⾃動復旧など
    • 複数のサーバー間でいい感じにコンテナを配置してくる
    • リソースを効率的に使⽤してくれる
    • Azure, AWS, GCPにマネージドサービスがあって始めやすい
    • デメリット
    • 定期的なアップデート、サポートは1年、運⽤コスト
    • Kubernetesを操作するための学習コスト
    • 必要なサーバー台数が多い
    24
    

    View Slide

25. まとめ
    • コンテナは⾼速な開発サイクルを回すには必要不可⽋
    • 学習コストはやや⾼めだけど、学習しといて損はない
    • Kubernetesの学習コストも⾼いが、学習しといて損はない
    • ただし、アプリの規模によってはK8sはオーバースペックかも？
    25
    

    View Slide

26. ⽇本仮想化技術株式会社 概要
    • 社名：⽇本仮想化技術株式会社
    • 英語名：VirtualTech Japan Inc.
    • 設⽴：2006年12⽉
    • 資本⾦：3,000万円
    • 本社：東京都渋⾕区渋⾕1-8-1
    • 取締役：宮原 徹（代表取締役社⻑兼CEO）、伊藤 宏通（取締役CTO）
    • スタッフ：11名（うち、8名が仮想化技術専⾨エンジニアです）
    • URL：http://VirtualTech.jp/
    • 仮想化技術に関する研究および開発
    • 仮想化技術に関する各種調査
    • 仮想化技術に関連したソフトウェアの開発
    • 仮想化技術を導⼊したシステムの構築
    • OpenStackの導⼊⽀援・新規機能開発
    26
    ベンダーニュートラルな
    独⽴系仮想化技術の
    エキスパート集団
    会社概要
    

    View Slide

27. OpenStackへの取り組み
    • 通信事業社でのOpenStack基盤の検討⽀援および構築・運⽤
    • NTTドコモ (2011年から技術評価を⽀援、商⽤利⽤に向けた検討・構
    築・運⽤を実施)
    • NTT⻄⽇本 (商⽤利⽤に向けた評価・検討の⽀援、プロジェクトマ
    ネージメント⽀援)
    • ⼤⼿通信事業社 (NFV基盤についての検証・評価⽀援)
    • ベアメタルOpenStackの開発
    • 仮想環境と物理環境をOpenStackで⼀括管理
    • 単⼀のイメージで仮想マシンと物理マシンの双⽅を起動可能
    • 2013年4⽉リリースのGrizzlyで本体にマージ
    27
    会社概要
    

    View Slide

28. OpenStack Summitでの発表実績
    28
    2014/11 OpenStack Summit Paris
    We spoke the knowledge and tips
    when building and operating OpenStack Cloud on
    100 Physical Servers.
    (Neutron HA, VXLAN performance,,,)
    会社概要
    2015/10 OpenStack Summit Tokyo
    We (NTT West, Canonical and VTJ)
    spoke ”Requirements for Providing Telecom
    Services on OpenStack-based Infrastructure”.
    

    View Slide

29. View Slide