DevOps｜知る×学ぶ
効率的なプロジェクトのすゝめ
2017年7月20日、21日、東京・虎ノ門ヒルズフォーラムで国内最大規模のオープンクラウドイベント「OpenStack Days Tokyo 2017」が開催された。7月21日、午後のセッションで、伊藤忠テクノソリューションズ株式会社(以下、CTC)、クラウドインテグレーション部 後藤 僚哉氏が登壇。OpenStackプロジェクトで蓄積した「べからず」「ノウハウ」を紹介、効率的なプロジェクトのすゝめ方についてご紹介します。
▼ ハイライト
1. OpenStack利用初心者に「べからず」を伝授
2. 事例で明らかになったCI/CDのTips
3. CI/CDからDevOpsへ
1. OpenStack利用初心者に「べからず」を伝授
「社内の仮想化環境を一歩進めたいと思っている情報システム担当者、クラウド化を進めたいがOpenStackがベストな選択なのか迷っている運用管理者、オープンソースを使ってインフラ構築をしたいが行き詰っている担当者、本セッションはそういう方々を対象としています」と、後藤は切り出した。
今回の講演テーマはCI/CDを使ってOpenStackをスマートに構築していこうというもの。後藤は、CTCで数々の仮想化インフラ構築に携わったのち、OpenStackインフラ構築を手掛け、OpenStack Kollaプロジェクトにも加わり、現在は、CI/CD、
DevOpsに取り組んでいる。「これまでのOpenStackプロジェクトで、初心者が陥りがちなポイントが分かってきました。しかしこれはCI/CDによって回避することができるのです」と後藤は言う。
伊藤忠テクノソリューションズ株式会社 後藤 僚哉氏
べからず1
OpenStackを仮想化インフラの代わりとする、あるいはコスト削減のために使うこと。そもそも、仮想化とクラウドでは設計思想が異なる。設計・運用を変えないままOpenStackへ移行すると、想定外の運用量増大やバグの頻発、欲しい機能がなくて困る、かえってコスト増などということが起きるという。
仮想化はホスト数、ライセンス数を減らす消極的な投資だが、OpenStackは大規模スケールアウトサービス、開発の高速化を目指す積極的な投資だ。そこで設計・運用を変えてOrchestratorによる自動化が必須となる。
べからず2
「バグが出きっているからと、古いバージョンを使う方がいい？」
OpenStackの古いバージョンを使ってシステム設計すると、問題が多発する場合がある。実はOpenStackの開発は新バージョンに集中している。旧バージョンのバックポートは限定的で、新しいバグも最新バージョンでしか修正されない。ただし、OpenStackではバージョンに関わらず「テスト」は必須である。構築後、変更後には必ずテストをすること。テストでは必要な要件が洗い出せていることが条件だ。
べからず3
スモールスタートだからと、今までどおりの構築手法で行おうとすること。OpenStack構築時に、「スモールスタートだから手作業構築でいいよね？ ドキュメントは今までのフォーマット渡します」という言葉をよく聞くと後藤は言う。
しかし実際に構築を始めてみると、小さい構成変更が大量に発生して全体が遅延してしまったり、ドキュメントのアップデートが追い付かずデグレが発生するといった事態に陥る。
OpenStackは実は色々なものを管理したがる。つまり管理する範囲が広くて、一ヵ所の変更が影響する範囲が多岐にわたるのだ。そこで、構築もテストも自動化しないとほころびが出る。
2. 事例で明らかになったCI/CDのTips
ここで、後藤が携わったCI/CDでのOpenStack構築事例を通して明らかになったTipsを紹介する。事例の要件は次の5つ。
- 最新のOpenStack機能を試したい（Private Cloud）
- アップデートを頻繁に繰り返す必要がある
- CentOS7を使いたい
- 労力を削減したい
- 手離れをよくしたい
これらを満足するためにCI/CDで構築し、アップデートを自動化。また、OpenStack Kolla*の最新バージョンを利用して、常にKollaイメージが自動で届き、管理者のタイミングでデプロイする仕組みとした。
*OpenStack Kolla：プロダクション用途に向けて、OpenStackの各種プロセスやサービスをDockerコンテナ化するプロジェクトで、Kolla Ansibleというデプロイ用ツールも用意されている。
まず第1のTipsは、CIツールとしてよく用いられているJenkinsではなく、GitLab-CIを採用したことだ。これは必要な機能を絞って、pipeline変更が容易なものをorchestratorとして選択した結果である。定義ファイルのわかりやすさから、インフラエンジニアでも扱いやすい手離れのよさがあり、最少の労力で最大の成果が得られるのだという。もちろん求める機能によってはPluginが豊富なJenkinsが適している場合もある。
次に、Configとコードを分離すべしというTipsが得られた。プロダクション、ステージングや複数の技術者が一斉に開発を行うための仮想環境など、複数の環境がある場合、コードの変更忘れや、特定の環境でのエラーなどが起こりやすくなる。タスクは共通とし、各環境のConfigで制御するほうがよい。コードと設定の分離はコードの冗長化を防ぎ、エラー回避ひいては労力削減につながる。
3番目のTipsは、依存性を極力排除すべしということだ。OpenStackコンテナをビルド/デプロイするexecutorをDocker化し、OpenStack環境やOSバージョンに依存しないようにすることで、他の環境へのデプロイが簡単になり、労力削減に成功した。
今回の事例を通して、特に印象に残ったのは、「CI/CDで変更箇所が小さなり縮退影響が小さくなった、品質のベースラインが上がった、更にSSHにつなぐ機会が減り開発に専念できるようになったこと」だと後藤は指摘している。
3. CI/CDからDevOpsへ
CI/CDによるOpenStackプロジェクトの次に来るのは、DevOpsであろう。DevOpsは、「文化」「プロセス」「人」「技術」という4要素の変革が必要とされる。その観点では、本日発表の内容は、「技術」でLevel2、「プロセス」「人」Level2に近いところにあるが、「文化」レベルの向上には組織内の連携を意識して強化していく必要がある、と後藤は言う。
CTCでは、OpenStackプロジェクトの実績をもとに、各種デモの紹介を社外勉強会で定期的に行っている。また、DevOpsのコンサルティングメニューも充実しているので、お問合せしてみてはどうか。
