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

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

Transcript

1. ここから始めるDevOps ⽇本仮想化技術株式会社 ⽥中 智明 ttanaka@VirtualTech.jp 2023/03/15 1 実⾏インフラ編
2. 発表者について • ⽥中 智明 • VTJ 技術部所属 • おしごと • DevOps案件 • Terraformのコード • 技術ブログ執筆 • かんたんDevOpsの仕組み作り • Software Design 3⽉号の特 集記事に執筆しました！ 2
3. 実⾏インフラとは • アプリケーションを実⾏する環境 • 環境を構築、運⽤、保守するめのツールや⼿法 • 環境を構築、保守するためのIaC • 実⾏環境としてコンテナとKubernetes 3
4. 環境を構築、保守するためのIaC • IaCはInfrastructure as Codeの略 • インフラの構成をコード化し、IaCツールを使って構築 • 構築⼿順はコード化されているため構築⼿順書を削減 • ⼈間の⼿を介さないことでヒューマンエラーの削減 • 何度でも同じ環境を構築できるため冪等性を担保 • 構築はコードを実⾏するだけでよくなり俗⼈化の排除 4
5. 従来の構築 5 ・それぞれのサーバーにSSHログインして⼿作業で構築 ・環境の差異は頑張って合わせる ・⻑期間運⽤していくと設定や状態が秘伝のタレに → スーパーエンジニアしか構築作業ができない ミドルウェアのインストール OSのアップグレード 設定の反映
6. IaCを利⽤した構築 6 ・エンジニアはコードを修正してIaCツールを実⾏するだけ ・IaCツールがコードに合わせて環境を構築してくれる ・コードを実⾏するだけなので誰でも同じ環境を⽤意できる ・コードのメンテナンスをしていればよくなる IaCツールが コードを実⾏ ミ ド ル ウ ェ ア の イ ン ス ト ー ル 設定の反映 OSのアップグレード コードを修正
7. コードを実⾏するためのIaCツール 7 • Ansible • AWS CloudFormation • Terraform • Chef • Puppet • etc…
8. コードを実⾏するためのIaCツール 8 • Ansible • AWS CloudFormation • Terraform • Chef • Puppet • etc… 選択肢が豊富でどれを選んだらいいかわからない…
9. IaCツールの種類 9 • IaCツールは2種類ある • 命令型と宣⾔型 • 命令型はあるべき状態を構築するための「⼿順」を宣⾔ • 宣⾔型はあるべき「状態」を宣⾔
10. 命令型 10 ・対象のサーバーはコレとコレとコレ ・SSHしてパッケージミラーをアップデート ・パッケージはコレがインストールされていなければインストール ・設定ファイルはココにおく ・…
11. 命令型 11 • メリット • ⼿作業と同じ「⼿順」として宣⾔するので、学習コストは低い • 汎⽤的なプログラミング⾔語で宣⾔できることが多く、学習コストが • デメリット • ⼿順を積み重ねた結果、あるべき状態になっていくので、⼿順の意図 が読みづらい • 実⾏した結果を宣⾔しているわけではないので、冪等性を担保しいづ らい
12. 命令型 12 • 命令型が向いている作業 • サーバーの中の設定 • ミドルウェアをインストールしたりOSの設定をしたり、など • 命令型ツール • Ansible • Chef • Shellスクリプト
13. 宣⾔型 13 ・こういう設定で ・こういうサーバーが何台 ・名前はこれ ・スペックはNコアのX GBメモリ ・…
14. 宣⾔型 14 • メリット • ⼿順を気にする必要がない • あるべき状態を宣⾔するだけなので、どういう状態のものができあ がってくるか、コードから読み取りやすい • 常にあるべき状態に維持されるので、冪等性を担保できる • デメリット • ツール独⾃の⾔語で宣⾔していくので学習コストが⾼い • ツールのバージョンによって書き⽅が違ったりするので、気軽にアッ プデートできない
15. 宣⾔型 15 • 宣⾔型が向いている作業 • クラウドの設定 • インスタンスが何台ほしい、など • 宣⾔型ツール • Terraform • Puppet
16. 16 かんたんDevOpsでは「Terraform」を使っています。
17. 実⾏環境としてコンテナとKubernetes 17 • コンテナ • 仮想化技術の⼀種 • 仮想マシンに⽐べてオーバーヘッドが少ない • アプリケーションと、その動作に必要な全てのものをパッケージング することで、アプリケーションをどの環境に移動しても実⾏可能に
18. 仮想マシン 18 Windows アプリ Linux アプリ macOS アプリ 物理サーバー ハイパーバイザー ・OSを問わず起動可能 ・完全なOSが起動するので、⽴ち上がりに時間がかかる ・1つのVMにつき、アプリケーション＋OS分のリソースが消費される VM VM VM
19. コンテナ 19 ランタイム ライブラリ アプリ ランタイム ライブラリ アプリ ランタイム ライブラリ アプリ 物理サーバー ホストOS ・コンテナ間でカーネルを共有、起動が⾼速 ・プロセスとファイルシステムを分離して別のシステムのように⾒せている ・1アプリにつき、アプリ分のリソースしか消費しない、OSは起動していない コンテナランタイム カーネル コンテナ コンテナ コンテナ
20. コンテナのメリット・デメリット • メリット • アプリをどの環境に移動しても同じように動作するので移植性が⾼い • 完全なOSが起動しているわけではないので、無駄なリソース消費がな い、起動が早い • 必要なものが全てパッケージングされているので管理が簡単 • デメリット • コンテナ技術の習得、学習コスト • ちょっとした修正でもコンテナを作り直す必要がある • アプリごとにコンテナ化され運⽤が複雑化しやすい 20
21. 実⾏環境としてコンテナとKubernetes 21 • Kubernetes • 読み「くばねてぃす」「くばねてす」「くーべねてぃす」 • 略記は「K8s」（けーえいつ、けーえいとえす、けーはちえす） • コンテナオーケストレーションツール • YAMLフォーマットのコードで宣⾔的にコンテナ運⽤ができる
22. 従来の運⽤ 22 ・それぞれのサーバーで1つのアプリを運⽤ ・アプリ間で空きリソースをシェアできない ・アプリに異常がないか監視、必要であれば復旧 ・対象のサーバーが増えると運⽤がカオスに rsyncやscpでアプリケーションを転送 ランタイムやミドルウェアをインストール 運⽤・監視
23. K8sを利⽤した運⽤ 23 ・エンジニアはコンテナのあるべき状態を宣⾔ ・コンテナの監視や運⽤はK8sにお任せ ・アプリが利⽤不可になったら、決められた⼿順で⾃動復旧 ・アプリのことはK8sに任せて、K8sの運⽤のみを考えればOK Kubernetes アプリ1 アプリ2 アプリ3 コンテナの状態を宣⾔
24. K8sのメリット・デメリット • メリット • 複雑化したコンテナの運⽤・保守をK8sに任せられる • アプリケーションの無停⽌デプロイ、障害の⾃動復旧など • 複数のサーバー間でいい感じにコンテナを配置してくる • リソースを効率的に使⽤してくれる • Azure, AWS, GCPにマネージドサービスがあって始めやすい • デメリット • 定期的なアップデート、サポートは1年、運⽤コスト • Kubernetesを操作するための学習コスト • 必要なサーバー台数が多い 24
25. まとめ • コンテナは⾼速な開発サイクルを回すには必要不可⽋ • 学習コストはやや⾼めだけど、学習しといて損はない • Kubernetesの学習コストも⾼いが、学習しといて損はない • ただし、アプリの規模によってはK8sはオーバースペックかも？ 25
26. ⽇本仮想化技術株式会社 概要 • 社名：⽇本仮想化技術株式会社 • 英語名：VirtualTech Japan Inc. • 設⽴：2006年12⽉ • 資本⾦：3,000万円 • 本社：東京都渋⾕区渋⾕1-8-1 • 取締役：宮原 徹（代表取締役社⻑兼CEO）、伊藤 宏通（取締役CTO） • スタッフ：11名（うち、8名が仮想化技術専⾨エンジニアです） • URL：http://VirtualTech.jp/ • 仮想化技術に関する研究および開発 • 仮想化技術に関する各種調査 • 仮想化技術に関連したソフトウェアの開発 • 仮想化技術を導⼊したシステムの構築 • OpenStackの導⼊⽀援・新規機能開発 26 ベンダーニュートラルな 独⽴系仮想化技術の エキスパート集団 会社概要
27. OpenStackへの取り組み • 通信事業社でのOpenStack基盤の検討⽀援および構築・運⽤ • NTTドコモ (2011年から技術評価を⽀援、商⽤利⽤に向けた検討・構 築・運⽤を実施) • NTT⻄⽇本 (商⽤利⽤に向けた評価・検討の⽀援、プロジェクトマ ネージメント⽀援) • ⼤⼿通信事業社 (NFV基盤についての検証・評価⽀援) • ベアメタルOpenStackの開発 • 仮想環境と物理環境をOpenStackで⼀括管理 • 単⼀のイメージで仮想マシンと物理マシンの双⽅を起動可能 • 2013年4⽉リリースのGrizzlyで本体にマージ 27 会社概要
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”.