「Infrastructure as Codeに疲れたので、僕たちが本来やりたかったことを整理する」を１年掛けて整理した
こんにちわ。rwle1212です。
本記事は JAWS Days 2020 で話す予定でしたが、昨今の事情によりオンライン開催となったため、登壇予定の内容を記事にしたものになります。
登壇していれば諸般の事情により左手首を骨折したネタが使えたのですが、ブログでは伝わらないので非常に残念な思いをしております。という話はどうでも良いので本題に入ります。
50分の登壇内容なので少々長くなりますが、お付き合いください。
JAWS Days 2019で登壇した内容の振り返り
昨年の JAWS Days 2019 で「Infrastructure as Codeに疲れたので、僕たちが本来やりたかったことを整理する」という内容で登壇しました。
まずは上のリンクに添付されているスライドを5分位で読めると思うので一読頂いて、下の文に進んで頂ければと思います。
そもそもInfrastructure as Codeとは何か
オライリー出版の「Infrastructure as Code ―クラウドにおけるサーバ管理の原則とプラクティス」を改めて読んでみて、そもそもの課題を洗い出してみました。詳細はリンク先の本をご購入ください。
Infrastructure as Codeにおける、そもそもの課題とは
Infrastructure as Codeの本では4つのカテゴライズが紹介されていました。
- ダイナミックインフラストラクチャープラットフォーム
- インフラストラクチャ定義ツール
- サーバ構成ツール
- インフラストラクチャサービス
元々Infrastructure as Code自体はPuppetやChefを代表するような「サーバ構成ツール」を対象としていましたが、APIでプラグラマブルに扱えるIaaS（ダイナミックインフラストラクチャープラットフォーム）が普及し、それらを扱うCloud FormationやTerraformなどのツールやサービス（インフラストラクチャ定義ツール）が登場することにより、これらもInfrastructure as Codeの対象に含まれるようになりました。
オライリー本の著者は主に「サーバ構成ツール」（PuppetやChef）の文脈が強いのですが（もちろん「インフラストラクチャ定義ツール」に関しても多く触れられています）、読み進めると著者の本来Infrastructure as Codeで解決したかった最も大きな課題は「ブラックボックスのサーバを運用するのが怖い」でした。
「ブラックボックスのサーバを運用するのが怖い」とは
例えば10台のサーバがあって、その内の1台を誰かが手作業で変更しました。その後も何か変更しているようです。
そんなある時、障害が起きました。何が原因か分かりません。何を変更されているのか分かりません。障害対応のための変更をすることによる二次影響も分かりません。問題のなかった時点へ復元しようにも変更した内容がわからないので、もう一度作り直すこと（再現性）ができません。
そうすると、手を入れることによる影響範囲も分からないため、手を入れるのが怖くなってしまいます。
そもそもITインフラが変化の障害や制約になるのではなく、変化を支えて実現する必要があります。そのためにはシステムの変更がユーザやITスタッフのストレスや大事件ではなく、日常作業になることが求められます。
DevOpsにも通じますが、インフラを継続的に改善し続ける環境を作るために、変化に強いインフラを作る必要があります。
手を入れるのが怖い環境を無くし、変化に強いインフラを作るために再現性、変更履歴、レビューなどを考え抜いたらコードで管理することに行き着いた。というのがInfrastructure as Codeの発端になります。
OS領域の場合はInfrastructure as Codeは必要
ここからは僕の個人的見解と、1年間で色んな方と話した内容を整理したものです。
「サーバ構成ツール」の場合はInfrastructure as Codeは必要です。なぜならOS領域は変更出来る箇所が多すぎます。/etc, /home, /usr/local/, /var/lib…1個のソフトウェアを入れるのにどこが変えられたのか、ミドルウェア単体で済むものから、hostsファイルと関連したり、iptablesを前提としたりしなかったり、関連するものを含めて設定を変えた場所や変更範囲など関連する範囲が広すぎます。
例で挙がってたように、Linuxサーバ上に手作業でインストールしたり、その後もゴニョゴニョしてたサーバがあったとして、完全にぶっ壊れたとする。当時の担当者は居ない。復元できますか？
そうなると変更加えるのが怖くなる。テストや各種調整、時には作業を切り戻して再チャレンジにn週間、、、と、リリースのサイクルが長くなる。
良くない。これが「ITインフラが変化の障害や制約になる」状態です。そのようにしないために、それらの変更履歴はどのように記録するのが良いのか、変更バージョンの履歴はどのように残すのが良いのか。
「サーバ構成ツール」を導入することで、OSへの変更内容が一元管理され可視化され、変更履歴やバージョン管理容易に行なえます。現在のサーバの状態も中に入らなくても構成情報を見ることで確認ができます。手作業と比べると適用作業は自動化されているためオペレーションミスも発生しにくいです。
変更できる箇所が圧倒的に多いOS領域に関して「サーバ構成ツール」が解決する課題は導入コストを払ってでも恩恵は大きいです。
クラウド領域の場合はInfrastructure as Codeは必要？「怖い」を無くすには？
「OSレベル」の話は、手作業でやっても変更履歴も付かないし現在の状態も中に入らないと分かりづらいです。しかし、AWSなどのクラウド領域に関しては
再現性はクリア
AWSなどのクラウド領域に関しては、Linuxと違って変更範囲や変更できるパラメータが限られていますし、パラメータはコンソール・APIを見れば分かります。
例えばSQSやSNS、DynamoDBなど、基本はUIに表示されているパラメータが全てなので、それをそのまま作れば同じものを作成できます（ユニーク性があるリソース除きます。またDB内などのデータは除きます）。
現在のパラメータからCLIコマンドを生成してくれたら尚良ですが、再現性は非常に高くクリアです。
バージョン管理・履歴管理もクリア
バージョン管理に関してはAWS Configがあります。最悪CloudTrailもあります。バージョン管理・履歴管理もクリアです。（もちろん対象外のサービスもあります）
レビューもクリア
作成・変更の際にCLIコマンドもしくはシェルスクリプトのラッパーをレビューすることも可能なので、レビューもクリアです。
（オライリー本でもAWS CLIをラップしたスクリプトをVersion Controle Systemで管理すればInfrastructure as Codeの第一歩とも言っています）
つまり、AWSなどのクラウド領域では「怖い」は少ない
再現性、変更履歴（わからないことによる怖さ）は「インフラストラクチャ定義ツール」では別の方法でも回避可能です。
クラウド領域ではInfrastructure as Codeが本来解決したかった課題は概ね解決されている説？あります。
もしかすると、軽く管理するぐらいで良いんじゃないか？ありがとうAWSさん！（積極的に媚びていくスタイル）
とは言え、コードで管理したい気持ちも分かります
Infrastructure as Codeの概念は非常に魅力的で優れています。でも残念ながら現時点では銀の弾丸ではなくてツールが追いついていないのが現状です。
コードで管理すると何が課題なのか
- 5分で作り終わる作業が10–30倍以上の時間を掛けてしまう
- 1回作るのに10–20分かかる（DBやCloudFrontなど）
- ビルドに時間がかかると結果を得るのに時間がかかる
- 実際はやってみないと分からない（Applyしないと分からない）
- 失敗を繰り返すのに時間がかかりテストしにくい
- 更にキレイに書きたいリファクタ病発動
- 書き方が自由が故に複雑化する
- バージョンアップによるコードの修正と新機能利用したい病
- たまに実行するとなぜか出る差分との戦い。いきなり適用するの「怖い」（アレ？怖さを無くすためにやってるのに・・？）
- tfstate壊れた時の復旧辛い
この辺りは過去の登壇資料を参照ください。
なお、作成に時間がかからないリソースは開発サイクルがかなり短くなるので良いです。例えば、DatadogのMonitorをTerraformで管理してますが数秒で反映されるので失敗してもすぐ直して適用出来るのでかなり楽です。
ツールが追いついていない
これらの課題に該当するリソースを「インフラストラクチャ定義ツール」で表現しようとするとかなりシンドいです。学習コスト、複雑性・拡張性、バージョンアップ、コード書く時間、テストなど、結構な時間を投資します。
クラウド領域では、大半のケースは「怖い」部分はクラウド側の機能がカバーしてくれているので「代替えで十分じゃない？」ってのが僕の主張になります。
ただ、事業内容やフェーズ、体制によってInfrastructure as Codeを利用した時のROIの高さは変わると思います。
事業内容やフェーズ、体制によってROIの高さは変わる
1. もしあなたがSIerの会社にいて、インフラ強い人達が数十人いたら
「インフラストラクチャ定義ツール」の引き継ぎはうまくいきますか？それはチームとして今後のキャリアパス的に伸ばしたいスキルですか？
さすがに同じような人たちが数十人も居れば、突き詰めれば良いでしょう。引き継ぎも比較的容易で、社内の他の案件時にも利用できるので再利用性は高まるでしょう。ROIはかなり高いと思います。
2. もしあなたがWeb系ベンチャーに配属されて、とあるゲームタイトルのインフラを5人~10人で見ることになったら
「インフラストラクチャ定義ツール」の引き継ぎはうまくいきますか？それはチームとして今後のキャリアパス的に伸ばしたいスキルですか？
5人~10人も居れば、突き詰めれば良いでしょう。引き継ぎも比較的容易ででしょう。次々にゲームタイトルが立ち上がる場合は再利用性は高まりますが、１個のタイトルでチームで作るだけなら再利用性はあまり高くないですね。しかし、同じスキルの人が多い場合はROIは比較的高いと思います。
3. もしあなたが小規模チームに配属されてバックエンド x 2、フロントエンド x 2しかいなかったら
「インフラストラクチャ定義ツール」の引き継ぎはうまくいきますか？それはチームとして今後のキャリアパス的に伸ばしたいスキルですか？
ちょっと厳しいですね。バックエンド・フロントエンドの人がTerraformやCloudFormationを使いこなしたいのかな？全員が覚えないとすると一部で属人化するのは心配ですね。
でも事業が圧倒的なスケールで成長する見込みなら「管理」は早い段階でしておいた方が良いでしょう。ブラックボックスを放置するとインフラが足を引っ張りかねないです。
「インフラストラクチャ定義ツール」が良いのか、「代替え手段」で割り切るのか、今後の事業・チームの体制・スキルマップ次第でROIは難しくなるところですね。
4. もしあなたがとあるチームに配属されて、MLエンジニア・データサイエンティスト中心の分析チームにバックエンドとして配属されました。Terraform/CloudFormationが分かるのはあなたしかいません。今後もMLエンジニア・データサイエンティスト中心にしか採用しなかったら
「インフラストラクチャ定義ツール」の引き継ぎはうまくいきますか？それはチームとして今後のキャリアパス的に伸ばしたいスキルですか？
MLエンジニア・データサイエンティストにも「インフラストラクチャ定義ツール（TerraformやCloudFormationなど）」を使ってもらうとすると、自分の領域ではないAWSを覚えないといけないし、それに加えて「インフラストラクチャ定義ツール」のツールの癖も覚えないといけない。ツールを使う上での自分達のポリシーも理解しないといけない。
でも、事業目線だと得意分野（データサイエンス）で力を発揮して価値にコミットして欲しい想いが強い。AWSを正しく使うために学ぶことはデータサイエンスの価値を上げることにも繋がることもあるからやぶさかかではないけど、「インフラストラクチャ定義ツール」はどこまでデータサイエンスに繋がるのか・・。
でも、チーム目線だと属人化防止したい。でも、覚えることが増える。今後のチーム体制的にも伸ばしたいスキルでもない。もっと覚えて欲しいことがある。これに対して「インフラストラクチャ定義ツール」は何を解決してくれる？
うーん。この事情だと、ROIはちょっと低いかな・・？
つまり、業態、事業フェーズ、組織・体制・文化と技術投資によって導入した方が良いかどうかは変わる
業態における価値基準の違い
どの事業でも優先すべきは事業の成長です。しかし業態によって何が価値になるかは変わります。
- SIerは再現性大事で類似案件による再利用性も高く、技術力自体が価値に繋がります。
- ユーザ企業は本業の価値貢献が基準になり技術力はあくまで価値実現の手段です。いつ使うか分からない再利用性よりも目先の機能開発を優先することも多いです。
つまり、業態によりROIは大きく異なります。
事業フェーズにおけるスピードと品質
- 事業検証フェーズは、長期目線より「事業検証」が優先されるのでスピード感ある開発が優先
- ある程度顧客が付いてくると、中長期的に安定化させるため品質を重視する
つまり、事業のフェーズによりROIは大きく異なります。
が「t_wadaさんの最近のスライド」ではスピード落としたから品質が上がる訳ではないとも
技術力のある人はある程度急いで作ったとしても一定以上の品質のコードを書くし、意図的に品質を落としたとしても速度はあまり上がらない。
逆に技術力が無い人が時間をかけて作ったとしても、その人の技術力以上の品質のコードは書けない。
組織・体制・文化と技術投資
チームの現在のスキルセット
- 最強集団を無限に集められるわけじゃなければ、強いスキル持ちじゃなくてもメンテナンスできるような妥協も大事です。
チームのマインドセット
- 「俺達は今後もガンガン学んで行くぜ！」という人達もいれば、「ちょっと最近子供が産まれて、、」とか「最近疲れてるのでゲームが楽しい」という人達もいるでしょう。価値観はそれぞれなので、強要すると良い事はありません。
技術投資（調査・学習）
- 絶対忘れてはならないのは技術投資。組織として現状に満足するのではなく、さらに継続的に良くしていくために新技術の調査やチームとしての学習に投資した方が良いです。そのような文化を作るのもエンジニアのチーム作りとしてはとても大事です。
会社・チームとして新しい技術への向き合うには
- 会社として、組織・チームをどうしていきたいかも重要です。何もしなくなるより失敗して痛い目あった方がよっぽど学びが多いです。そのような行動を評価する評価制度や文化作りは非常に重要です。
このような組織・体制・文化と技術投資判断によってROIは変わります。これらの前提条件を踏まえて自社・自部署等でROIが合うのかを考えましょう。
とは言いつつ、まずはやっちゃって失敗しようよ。とは思っています。
一回失敗すればいい
ここまで読まれた方はもしかしたらネガティブ・キャンペーンに聞こえたかも知れませんが、「Infrastructure as Codeやるべき！」「全部をコードで管理すべき！」みたいな風潮はシンドいので無くしたいだけです。僕は失敗も含めて技術投資をガンガンしていくスタイルなので、色々な失敗を踏まえて今の考えに至っています。体験しないと分からないことも多いです。
この記事を読んで「じゃあやらなくていいや」となるのではなく、「やってみたけど、やっぱり失敗やったわ。腹落ちした！」とか「やってみたけど、言うても難しくなく上手いこといったよ！こういう進め方がオススメ :)」とかをどんどん公開してほしいです。これらの状況を踏まえて改めて本質的な課題を捉えてみんなで問題定義を行い解決していければと思います。
もしそういう環境下におらずモヤモヤしているならJAWS-UGに参加すると応援してくれたりアドバイスをくれます。JAWS-UGの人たちは前向きな人が大好きです。昨今の事情で直近ではオフラインのコミュニティはやりずらいですが、懇親会などに参加し相談すれば前に進むための回答をくれるので、ぜひ参加いただき失敗・成功談をアウトプットし、今回のJAWS Daysのテーマである「サメの恩返し」を行って頂ければと思います。
失敗から学ぶことは非常に多いため、ぜひ失敗を糧に成長していきましょう。
Appendix
とはいえ「インフラストラクチャ定義ツール」を利用する時に心がけていること
概念の話や組織論が多くなったのでここらで技術的な話を・・。
結論としては「シンプルで行こう」です。
複雑に作るのは誰でもできますが、シンプルに作るのは難しいです。そもそも「シンプルとは？」の問いも問い続ける必要があります。
個人的には「作らない」「作り込まない」が一番シンプルだと思っていますので、基本は「如何に作らずに作れるか」をベースにしています。
そのため、最近Terraformで心がけていることは「作ったとしても作り込まない」「初学者に優しいコード」を意識しています。具体的には「ModuleやFunctionは基本排除」「あちこち 参照しないと追えない実装にはしない」など、この辺りはQiitaに公開しているのでそちらを参照ください。
以上、長文にお付き合いいただきありがとうございました。
