こちらは【LayerX Advent Calender 2021】の29日目の記事です。昨日の記事はこちら。
明日は@SATOKEN_Xさんがなにかを書いてくれる予定です。
こんにちは、LayerX インボイス・ワークフローのOCRの開発を主に担当しているtomoakiです。最近は自宅でパンを焼くことにハマっています。いろんな種類の小麦粉で試したいのですが、kg単位でしか買えない小麦粉がほとんで、なかなか気軽に買えないのが最近の悩みです。
さて、最近社内用のデータ管理基盤のインフラを構築する機会を頂いたのですが、その時LayerXサービス群のインフラ設計が非常に再利用しやすく、インフラ未経験の私でも他の業務も並行で行いつつ2週間ほどでサービスインフラを構築できたので、初心者目線で「ここわかりやすくて助かった！」みたいなところを紹介していきたいと思います。なお弊社のインフラはAWSを利用しています。
TL; DR
- LayerXサービス群のインフラはTerraformで再利用しやすく管理されており、インフラ未経験のエンジニアでもサクッとサービスインフラを構築できた。
- 例えば、Terraformのディレクトリ・ファイルの構造や、環境変数の使い方が工夫されていたので再利用しやすかった。
- また、タグを活用し、各リソースがどのレポジトリで管理され、どのような役割を持っているかが定義してあったので、初見でも既存の設計が理解しやすかった。
私がどれくらいの初心者だったかと言いますと、お恥ずかしながらTerraformに関してはplanとapplyすら知らない状態で、なんとなく「コードでインフラを管理できるもの」くらいの認識でした。AWSも業務でたまにS3にあるファイルを見るくらいで他のサービスはほとんど知らない状態でした。
なので以下で紹介するtipsが、今後サービスのインフラを触れるエンジニアを増やしていきたいぞという方のお役に立てば嬉しいなと思っています。
LayerXサービス群のインフラ
まず初めに、LayerXサービス群のインフラの設計を紹介したいと思います。 インフラの構成図はざっくり以下のようになっています。
詳しくはこちらのブログをご覧ください。
さて、今回私が作ることになった社内用のデータ管理基盤のインフラの構成図は以下のような感じです。
かなり、LayerXサービス群から流用できそうなところが多そうなのが見て取れます。 それでは、実際に構築してみて再利用しやすかった点を紹介していきたいと思います。
ほぼ全てのリソースをコードで管理してるから再利用しやすい
まずはやっぱりこれですね。同じリソースを定義するときは、本当にコピペするだけで済むので、えっこれだけで本当にいいの？と一瞬不安になるレベルですが、全く問題ありません。
後ほど紹介しますが、localやvarを活用することで、本当に一文字も変える必要なくコピペできるのでビックリしました。 手動で設定したのは、Secret Managerの値くらいです。（Secret Managerのリソース自体はTerraformで管理しています）
Terraformのディレクトリの構造がとてもシンプル
Terraformのディレクトリの構造はフラットに配置しているので、どこに何が定義されているかで迷ったことはありません。ファイル名も(provider)_(resource)_(target).tfという規則で命名しているので、どこにどのリソースを定義すればいいかが一目瞭然でした。
本番環境と開発環境でAWSのアカウントを分けてるので安心して開発できる
初心者がインフラを触るときに一番怖いのは、変更してはいけない箇所をうっかりいじってしまい顧客影響が出てしまうことです。デプロイで失敗したときなど、開発環境だったからこそ安心してデバッグすることができました。
環境特有やプロジェクト固有の定数は全て環境変数で定義されてるので同じリソースを作るときはコピペするだけで済む
環境変数は.tfvarsファイルで定義してenvディレクトリに配置し、Terraformコマンド実行時に引数で指定します。また、プロジェクト固有の定数はlocals.tfで定義しています。 したがって、既存のリソースと同じものを作るときはをコピペするだけで済みます。本当に何もいじる必要はありません。
リソースのセキュリティレベルや対応するTerraformのレポジトリをタグで示すことで、GUIをいじるときに安心
初心者だと特にそうですが、これ勝手にいじっていいのかな、、、と不安になります。 必要とするセキュリティのレベルをタグで管理したり、どのリソースがどのレポジトリで管理されているかをタグで管理することで、うっかり意図しない変更をしてしまうのを防ぎやすくなります。
どのリソースがどのレポジトリで管理されているかは、レポジトリ内の全リソースに共通して付与するタグとしてlocals.tfでmanaged_by = "レポジトリ名"のように定義し、各リソース定義のdescriptionに代入しています。
GUI上でリソースの設定を変更する時も「このリソースはこのレポジトリで管理されている」ということが一目見てわかるので非常に助かります。
また、セキュリティレベルを管理するタグとしてconfidentialityというものを定義し、各レポジトリをsensitive, confidencial, private, proprietary, publicのいずれかに区分しています。 confidentialなものについては権限周りの設定等を変更する際に一層慎重に行おうという意識が生まれたり、少しでも自信がない部分はレビューしてもらおうという意識が生まれます。
タグの活用のメリットに関しては上記以外にもいくつかありますので、興味ある方は是非こちらをご覧ください。 speakerdeck.com
終わりに
LayerXではエンジニアを積極的に採用しています。私のように、フルスタックじゃないエンジニアでも新しい領域にチャレンジし、自分のスキルを上げられる環境がありますので、「LayerXはフルスタックじゃないとダメなんでしょ、、、？」と思っている方もお気軽にご応募ください！最近はフロント・バックエンドで分けた募集要項も公開しています！
応募する前にまずは中の人と話してみたいという方は是非カジュアル面談をさせてください！ meety.net
また、インフラについてもっと詳しい話が聞きたいよという方はこちらのmeetyがおすすめです！ meety.net
また、LayerXの守護神ことshnjtkさんが先日awsj communityさんのイベントにて、チームでのインフラ管理における要点について発表していますので是非ご覧ください！（43:25~） youtu.be スライドはこちら
