IaC で作る さくらのクラウド デザインパターン①

前書き

IaC(Infrastructure as code) してますか、ということで、プリセールスなのに IaC 大好きな者として、技術が本職ではないながらも、こういうことやってます、というのを公開してみようと思います。
Terraform くらいしか触れないので、そんなのは Infrastructure as config だ、と言われてしまうかもしれませんが、IaC をこれからはじめてみようかなという方や、同じく技術が本職では無い方に向けての入門的なご紹介、としつつ、詳しい方が見てくださって、もっといい方法あるよとかの情報もらえたらラッキーだな、ということで、記事にしてみようと思います。
それでいて、実践的な仕事にも役立つように、今回はさくらのクラウドを例にして、デザインパターンとして構成図や見積もりも交えて、どんな構成が手軽に作れるのか、というのをイメージしやすいようにしてみたいと思います。
これまで興味が無かった人にも、やってみようかなと思ってもらえたら幸いです。

なぜ IaC を使うのか？

なんかかっこいいから・・・というのが個人的な一番の理由な気もしますし、単純に取り組んでいてとても楽しいのも事実です。
自分が ITインフラ関連のプリセールスを仕事にしていて、パブリックなクラウドサービス含め、サーバ環境構築が身近だから、というのも大きいかもしれません。
やってみるとわかるのですが、非常に大きなメリットがあることが実感できます。
例えば以下のようなところです。

1. 作業効率が上がる
2. 無駄をなくせる

1点目でいうと、特に AWS は顕著ですが、シンプルな構成であっても、作成するリソースは実はすごく多い、というのがあると思います。
もちろんブラウザのコントロールパネル(マネジメントコンソール)上で作成すると、自動的に裏でいろいろと動いて、デフォルト設定をまとめて作ってくれるなど、複雑なことをなるべく意識させず、簡単に作れるような工夫もありますが、細かくしっかり設計して作る場合には、自動任せにはせず、手動でちゃんとすべてのリソースを作ることになると思います。
そうなると、結構大変なんですよね。
あっちのメニューやこっちのメニューにいったりきたりが必要で、わかっていてもこんがらがってくると思います。
当然時間もそれだけかかってくるわけで、仕事上だと納期なんかにも影響してきます。
それに比べて、コード化して管理していると、基本的には似たような構成を何度も作ることになるため、再利用して一部を変更するだけで、あっという間に毎回環境構築を終えることができるようになります。
昔よくあった、お客様のご希望で今すぐ構築してほしい、そんなすぐには無理、の営業とシステムエンジニアの攻防が無くなるわけです。
あぁその構成なら 10分で作れるわ、みたいな。
(もちろん実際には納品物はいるのかとかパラメータの確認とかダブルチェックとか、いろいろあるので、周辺作業の時間はかかるわけですが・・・)
削除するときもコマンド一発ですべて消せますので、非常に楽です。
複雑な構成になるほど、消したつもりが残ってしまった、というのもありがちですしね。
特に私のように、検証などで一時的に作成することが多いと、非常に便利に使えます。
検証利用でよくあるのが、作りっぱなしでリソースを放置することで、消せって言われない限りずっと残り続けていたりするんですよね。
理由を聞くと、また使うかもしれないからとか、手をかけて作ったから消すのがもったいないとか、そういうのばかりで・・・
無駄なリソースを残し続けていると、会社のお金を無駄に利用していることにもなりますし、不要になったらすぐに消す、必要な時にだけ自動でさくっと作る、ということができるようにしておくのは、とてもよいことだと思っています。

とはいえ、いいことばかりではなく、以下については考慮が必要です。

1. 複数人で作業する必要があるか
2. 運用も含めてずっと管理していくのか
3. 学習コスト

ひとりで使うだけならいいのですが、複数人でともに作業するとなると、管理方法が問題になりますし、運用も考慮するとさまざまなことを気にかける必要がでてきます。
(状態の管理方法や排他的なロック、Terraform には実装されていないけど、サービスには存在するリソースを作る必要が出てきた場合の対処方法、などなど・・・)
また、今回ご紹介するコードを使えば、簡単にすぐに環境構築ができるものの、やはりちゃんと使うとなると、Terraform の使い方(HCLの書き方や各プロバイダ、モジュール等の利用方法)をきちんと調べる必要はでてくるので、プログラム言語などに比べるとかなり簡単とはいえ、学習コストはある程度かかるのは事実です。
(ここは私にとっては楽しい部類に入るのですが ^^;)

開発環境の用意

ということで、それでは IaC をはじめましょう、と言いたいところですが、まずは実行環境が必要となります。
Linux のコマンド実行環境があればなんでもいいのですが、以下では WSL2 を利用して Ubuntu22.04 の環境を準備し、その中で実行することを前提に説明していますので、この環境を作ってみてください。
https://github.com/shztki/sakura_design_pattern/blob/main/README.md

パスワードを直接コードに書かないようにしてセキュリティを意識したり、ディレクトリを移動するだけで環境変数やアクセスキーを切り替えて、安全かつ効率的に作業できるようにしたり、実行環境構築自体を Ansible化して自動でできるようにしたり、といった、今自分にできる最大限の工夫は盛り込んだつもりなので、ぜひ便利に使ってもらえたらと思います。
もっと良いアイディアありましたら、ぜひ共有してもらえるとうれしいです。
ちなみに自分はこのあとに、tmux でペイン分けて作業できるようにしたり、シェルは fish に変えたり、powerline を使って好みのデザインに変えたり、その他便利なツールをインストールして、より使いやすくカスタマイズしていますので、みなさんもぜひ自分だけの開発環境づくりを楽しんでください！

デザインパターン 1

ではいよいよ、IaC を使って、サーバ環境の構築を試してみましょう。
まずはサーバ 1台の単純な構成からです。

詳細については、README で解説していますので、こちらをご確認ください。
https://github.com/shztki/sakura_design_pattern/blob/main/01_shared_internet_web/README.md

variables.tf 内のパラメータを変えることで、利用するゾーンだったり、名前、スペックや台数、OS などが手軽に変更できることを、ぜひ体感してください。
ベースとなる、こういったテンプレートをひとつ持っているだけでも、変数を変えながらさまざまな構築作業に流用できるので、便利に使えると思います。

デザインパターン 2

サーバ 2台で WEB/DB 構成を作るパターンです。

詳細については、README で解説していますので、こちらをご確認ください。
https://github.com/shztki/sakura_design_pattern/blob/main/02_shared_internet_web_db/README.md

コストを抑えるために、あえて WEBサーバ兼NATゲートウェイ兼踏み台、となるようにしていますが、パブリッククラウド(AWS)あたりのベストプラクティス的に考えると、単機能であるべきなので、デザインパターン 3/4 あたりも検討してみるのがよいと思います。

デザインパターン 3

サーバ 2台で WEB/DB 構成を作りつつ、NATゲートウェイ兼保守ラインとして VPCルータ(スタンダード)を使うパターンです。

詳細については、README で解説していますので、こちらをご確認ください。
https://github.com/shztki/sakura_design_pattern/blob/main/03_shared_internet_web_db_vpc/README.md

VPCルータ(スタンダード)というファイアウォールアプライアンスを使うことで、ネットワークの構成をいろいろと変えたりできる構成になっています。
VPNの利用を前提とした構成に変えたりもできますし、ぜひいろいろとネットワーク設計を考えてみてください。

デザインパターン 4

サーバ 2台でプライベートネットワークを別にした WEB/DB 構成を作りつつ、ファイアウォールとして VPCルータ(プレミアム)を使い、NAT構成にしたパターンです。

詳細については、README で解説していますので、こちらをご確認ください。
https://github.com/shztki/sakura_design_pattern/blob/main/04_dedicated_internet_web_db_vpc/README.md

ルータ＋スイッチというリソースを使うことで、グローバルIPアドレスの CIDR やインターネット側の帯域を指定できる構成です。
パターン3 と比べて、よりネットワーク設計の幅が広がりますね。
とはいえ、簡易的なファイアウォールのため、メーカー製のファイアウォールと比較するとできることは限られてしまうので、サービス仕様についてはしっかり把握して設計することが重要です。
なおこのデザインパターンには、サーバ内の環境構築用に Ansible のサンプルコードも含めています。
サンプルでは Apache の構築や、MariaDB のユーザ、データベース作成程度までですが、必要な処理を追加してもらうことで、WEBサーバとしての構築や、DBサーバとしての構築も、完全自動化することが可能です。
このあたりも楽しいので、ぜひトライしてみてもらえたらうれしいです！

最後に

いかがだったでしょうか？
試してみたら自分にも簡単にできた！、とかだったらうれしいのですが。
ぜひぜひ、Terraform や Ansible を使った自動化に、取り組んでもらうきっかけになったら幸いです。
なお、まずは代表的なデザインパターンとして 4つをご紹介しましたが、他にも自動バックアップだったり、ロードバランサを組み込んだ構成だったり、ゾーンやリージョンを分けた構成なども、デザインパターンとしてご紹介したいなと思いますので、できあがったらまたいずれ公開したいなと思います。
それでは、どうぞ楽しい IaC ライフを！！