背景
私は仕事柄複数のプロジェクトに並列で関わらせていただいてます。
プロジェクト毎に利用しているクラウドサービスも様々で、更に最近はマルチクラウドを利用されているお客様も増えてきたことから、結果としてAWSとAzure、GCPを常に並列で触っています。
例えば去年の振り返り記事を見てみても様々なサービスを利用しました。
扱っているサービスの多さから、同僚やお客様に勉強法を聞かれることが多いのですが、「愚直にやっているだけで、特に効率良いこともしてないです」というのが決まった答えでした。
ただ、一昨年くらいから新サービスや久しぶりに使うサービスのキャッチアップの勉強方法として定着してきたものがあり、それが記事タイトルです。
クラウドサービスのキャッチアップにおける課題
新しいサービスを使う時には当然勉強をするのですが、その際に個人的に以下のような課題がありました。
サービス間連携が多い
クラウドのサービスを見ると、複数のサービスが連携しているのが通常で、単体のサービスで動かすものは少ないと思います。 例えば、一つのサービスを利用するにも、そのサービスのデータストアにはサービスAとサービスBが選択できて、監視ではサービスCを使っていて、のような形が多いかなと感じます。
芋づる式に連携するサービスに対して、末端まで神経の行き届いた設計をしていくところに難しさを感じています。
新機能追加のスピードが速い
クラウドサービスは変化が早いので以前使ったことがあるサービスでも1年もすれば別物になっていることが少なくありません。
利用している全てのサービスの更新情報に追従するのは難しく、利用時には最新の機能をキャッチアップする必要があります。
後から「あ、そんな機能があったんだ」という風に、サービス毎の設定や機能を見逃してしまうことがあると感じています。
すぐ忘れる
いきなり個人的なレベル低い話ですみません。 変化が早いからか、覚えることが多いからか、そもそもの記憶力の無さなのか、すぐ忘れます。1ヵ月前に設計した内容を忘れていることもあります。
本当は知識は積み上げていきたいところなので、自分があれこれ悩んで、試して作った設計を将来の資産として残したいと感じています。
上記のように課題だらけで悩みが尽きません。何とかならないかと様々な方法やアプローチを試行錯誤してました。その結果ここ2年くらい定着してきたのがコードから勉強するスタイルです。
勉強時にインフラコードを書くようにしてみた
新しい、または久しぶりに触るサービスをキャッチアップするぞ！となった時の勉強ステップを書いてみます。
以前のステップ
- ① スライドや動画WEB情報で概要を把握
- ② クラウド管理画面から基本的な機能を構築してみる
- ➂ 認定試験あれば取る
- ④ 実際に何か作ってみる・設計ポイント整理
- ⑤ 実プロジェクト
以前のステップです。問題となるのは④です。特に辛いと感じているポイントは以下です。
- ➂と④が時期が空いていることが多いので忘れている
- ②の時に残していた情報が役立たない（メモ取るのが下手）
- 設計ポイントの整理が難しい
他に特徴あるとすれば➂でしょうか。 会社でクラウド認定試験で報奨金が出るので、入門の時点で関連するものは取ってしまいます。ベンダーの認定試験は慣れてくると初めての分野でも1週間くらいあれば合格できるようになります。1週間の勉強で何が身につくとかは無いのですが、クラウドベンダーの設計思想みたいなものが俯瞰できるので、タイミング的にここが個人的なベストタイミングです。
現在のステップ
- ① スライドや動画WEB情報で概要を把握
- ② コードで基本的な機能を構築してみる
- ➂ 認定試験あれば取る
- ④ ②で作ったコードを修正・拡張し何か作ってみる
- ⑤ 実プロジェクト
こちらが現在のステップです。
②と④がインフラのコードを書くことで変わっています。ここについてもう少し詳しく書いてみます。
Infrastructure as Codeについて
インフラのコード化についてもう少し書いてみます。
使っているツール
以下のようなツールを使っています。
| Cloud | Tool |
|---|---|
| AWS | Cloudformation/CDK |
| Azure | Terraform |
| GCP | Terraform |
AWSだけCloudformaion使っています。一番の理由は慣れです。AWSに関してはWEBの情報も書籍の情報も Cloudformation > Terraform だと感じます。ある程度の規模になったらCDKも便利です。
AzureとGCPはTerraformが使いやすく情報も豊富だと思います。Terraformの良い点はGithubに公開されていることもあり、詰まった時にトラブルシュートしやすいが早いのも助かります。
例えばAzureなら公式ドキュメントとGithub見れば大抵のことはわかります。
デプロイに管理画面使うことは少ないのですが、Viewerとしては良く使います。コードで論理的な繋がりを確認しながら、管理画面で見ていくと、管理画面での設定項目の表現方法などから、また違う発見もあったりします。
書き切れないので書いてないですが、CloudformationとTerraform以外にもRaspberry Piで作っているIoT Gatewayや、サービス管理用のVM構築はAnsibleで管理しています。
メリット
自分が感じているメリットを挙げます。
細部まで整合性の取れた設計がしやすい
別サービスとの連携が必要だったり、複数の権限が必要なサービスは設定が多段になり複雑になりがちで、整合性の取れた設計が難しいと感じています。
例えば、管理画面から作成すると裏で色々な処理が動き、不必要な権限が付いてしまったり、コンポーネントの命名が実態を表していなかったりといったことが良くあります。
コード内でパラメータや変数・定数、参照などで組み込んでいくとキレイに整理できることが多いと感じています。コードで記述することで自ずと論理関係を追うことになり、末端まで整合性の取れた設計としやすい気がします。
実例を一つ挙げます。AWSのGreengrass(V1)についてです。Greengrass(V1)は以下のスライドに表されているように、複数のコンポーネントが複雑に絡み合ってサービスが構成されています。 しかし、これがAWS提供のボタンやスクリプト一つで自動生成されます。人目に触れることなくこの複雑な構成をデプロイできてしまうことになります。
私は自動作成した後に、このスライドを見ながら、管理画面でコンポーネントを追っていって理解した気になっていたのですが、Cloudformationで作り直して初めて肌でわかったコンポーネント間の関係性みたいなのがあり、命名を大幅に変えたことがありました。
最近では珍しくコード化を後回しにしていた部分だったので、失敗したな・・と反省したことがありました。
ここは完全に個人的な感覚な気もしますが、絵よりも自然言語よりも自分の手で書いたコードが論理関係を追いやすいと感じます。
抜け漏れが少なくなる
管理画面のGUIで設定すると、ウィザードベースで最低限必要な基本構成が簡単に組めるようになっていることが多いです。
別の見方をすると基本構成があり、そこに必要な機能を加えていくアプローチに感じます。
メリットも大きいのですが、細かな設定などはタブを開いて、ボタンを押してのように奥の方にあり気付かない場合もあったりします。最新のサービスなどはGUIからは設定できないものもあります。(時々IaCからも設定できないものもありますが）
コードの場合はどうでしょう。例としてCloudformationの AWS::ECS::Service のページ載せてみました。
AWS::ECS::Service - AWS CloudFormation
IaCのドキュメントを見ると設定できる項目の一覧が最初に出てきます。 これは管理画面のGUIの場合と逆で、最初に全量があり、必要なモノだけを残していくアプローチに感じます。
知らなかった設定や、機能が見つかることもありますし、今必須で無い機能についても知識を蓄えることができます。標準機能で存在したのに、調査不足で作り込んでしまうようなことが少なくなるなと感じています。
知識の整理・蓄積ができる
初めてサービスに触れて、数ヶ月間全く触らない期間をおいた後に本格的に利用することになる場合など、以前調べたことをすっかり忘れてしまっていることが良くあります。
嫌というほど自分の記憶力の無さを感じているので、可能な限り知識や考えを残すように意識しています。
知識の残し方には色々な形があります。スライドや表計算ソフト、ブログ、Wiki。。。コードもその一つかなと考えています。
以下が自分の中での情報蓄積方法の比較です。一長一短ですし、得意不得意もあると思いますが、コードはクラウドサービスの設計等の知識を残す手段の一つとしてはとても合っていると感じます。
| 知識蓄積形式 | 作成コスト | 読み取りコスト | 所感 |
|---|---|---|---|
| 図 | 高 | 低 | アイデアが降りてこないコトがある・・ |
| 文章 | 低 | 高 | 残せる知識の対象の範囲が広いが、抽象度が高い。 |
| コード | 低 | 中 | 残せる知識の対象の範囲が狭いが、具体的。 (PlantUMLなど使うと範囲は広くなる） |
情報の整理方法というのは、それ自体がアイデアだったりして、降りてこないと後から見て読み取りコストが高い整理方法になってしまうことがあります。対象が複雑であるなら尚更です。
その点、IaCのコードというのは便利で、あまり整理すること考えずに動くように書くだけでもある程度クラウドサービスの情報が整理されます。後からリファクタリングするとサービス間の連携への理解が進むという二毛作、三毛作的な良さもあると感じています。
開発中の細かな設定内容もEXCELの設定一覧や、手順書のCLIのパラメータに追加するより、コードで書いてGitで管理するのがやりやすく感じています。
デメリット
デメリットというデメリットは無いと思うのですが、大前提としてコードを書くのが苦でないことが前提の話なので、人によっては心理的ハードルがあるのかなと思います。
「コード」という言葉使ってますが、複雑なアルゴリズムとか無いので、アプリケーションコードが苦手な人でも試してみる価値はあると思います。
さいごに
コードで残す前の知識と、コードで残し始めた後の知識は後者の方が圧倒的に自分の中にノウハウとして残っている気がしています。もし、ここまで読んでくれた方で、あまり手を付けたことが無い人がいたら是非試してみてください。
