フリュー株式会社フリュー株式会社の開発者が技術情報を発信するブログです。CDKで新規プロダクトを構築して感じた嬉しいポイント(について社内発表をしたよ)AWSはじめにあけましておめでとうございます。ピクトリンク事業部開発部サーバサイド開発課のkitajimaです。2023年もよろしくお願いいたします。今年の抱負は「鼻うがいを続ける」です。CDKを利用したピクトリンク連携用プロダクトのインフラ構築及びデプロイの自動化」(外部発信に合わせ一部表記を変更)と題して私が発表しました。外部にも同内容を発信したく、社外秘など一部改変して紹介させていただきます。※技術交流会とは弊社で年に一度行われる社内の発表会です。異なる事業部の合計4~5名ほどがそれぞれの業務に取り入れた技術や獲得した知見、その他発信したいことを発表する場です。普段あまり見ることのできない他事業部の取り組みや技術を知れる機会として、とても楽しい行事になっています。CDKを用いてインフラ構築およびデプロイの自動化を行いました。Android版)と連携することで、プレイ後にプリが通知として届くようになるという機能です。プリ機に"ログインする"というイメージを持ってもらうとわかりやすいかもしれません。詳しくは、弊社ニュースをご覧ください。連携サーバは以下のような構成になっています(一部改変&簡略化)。プリ機に向けて、連携用のAPIを提供しています。Lambdaのサーバレス構成を採用しています。Code)の一種です。プログラミング言語を使用してコードを管理します。2019年登場で、弊チームでは2021年ごろから利用しています。詳しくは公式ドキュメントを参照いただきたいですが、大まかに流れを説明します。initを叩いてプロジェクトを作成します。typescript以下のようなディレクトリ構成が作成されます。Libraryを使用します。作成されたlib/sample-stack.tsに書いていきます。}}ここではLambda関数を1つ作成しました。deployでデプロイできます。diffを叩くことでコードとデプロイされているインフラとの差分を確認できます。destroyを叩くことでデプロイされているインフラをスタック単位で破棄できます。destroyCDK嬉しいポイントプログラミング言語を使えるCDKではJavaScript、TypeScript、Python、Java、C#(プレビュー版としてGo)がサポートされています。CloudFormation(yaml/jsonを使用するIaC)に比べ、弊チームのようなサーバサイドの人間と親和性が高く、学習コストも低いです。Lambda実装と同じ言語を使えるまた、CDKのサポート言語はLambdaのサポート言語(Java、Go、PowerShell、Node.js、C#、Python、Ruby)と共通しているものが多いです。特徴そのため、インフラ構築とLambdaの実装で同じ言語を使用すればスイッチングコストが減るのです!なお、今回はCDK、LambdaともにTypeScriptで書くことにしました。ドキュメントやサンプル、参考記事が充実しているためです。実装に時間をかけられる例として連携サーバに改修が入り、提供するエンドポイントを1つ増やしたいケースを想定します。Lambdaの実装を書くCDKの範囲からは外れる工程ですが、まずLambdaの実装を書きます。aws_lambda.Functionをもう一個newするTypeScriptで実装しているため、今回はaws_lambda.Functionを拡張したaws_lambda.NodejsFunctionを使用しています。既存のaws_apigateway.RestApiにリソースを追加し、そのリソースにLambda関数を統合します。以下のようにメソッドを呼んであげるだけです。3)はさっと作れて肝心の実装(1)に時間をかけられることが大きかったです。インフラと実装の関係が分かりやすい本プロダクトでは実装とインフラを同一のリポジトリでgit管理しています。initしたのち、Lambdaの実装を置くためのlambdaディレクトリを掘りました。Gateway⇔Lambda⇔実装の関係性をコードを追うことで理解できます。gitのコミットログから変更の理由も読み取りやすくなります。以上のように、自分達が作ったインフラを実装との関係性も含め把握できる点も非常に嬉しかったです。実装も含めてデプロイできるインフラと実装の関係が分かりやすいに関連して、Lambdaの実装とインフラを同一のCDKプロジェクトに配置していることで受けられる恩恵があります。deployさえ叩けば、インフラだけでなく実装の差分も含めてデプロイできるのです。コードの管理)にもありますように、CDKでLambdaコードの管理を行う何らかの手法を選択する必要があります。弊チームでどの方法を採ったかの経緯はこちらの記事で詳しく紹介しておりますので、是非併せてご覧ください。Actionsで自動化しました。deployを叩いてくれるActionsを定義しました。./cdkインフラのテストを自動化できるaws-cdk-lib.assertionsというテスト用モジュールを用いるとインフラのテストコードが書けます。"nodejs16.x",});CDKは便利な反面インフラ構築が抽象化されており、実際に作成されるリソースたちを把握することが大変だと私は感じました。今後はこのようにインフラのテストも自動化していきたいです。(基本的な構成要素)が含まれます。Resources)CFnと1対1に対応したConstructです。Constructより記述が長くなります。Constructがまだ提供されていない新しめのAWSサービスを構築する際には使えそうです。Construct単一のリソースをいい感じに構築するために抽象化されたConstructです。プロパティを設定しない場合はいい感じのデフォルト値を使用してくれたり、リソースの操作を行う直感的なメソッドが提供されていたりします。基本的にこちらを使用することが多いです。Construct(Patterns)複数のリソースからなる、一般的なユースケースに最適な環境をネットワーク周りも含めて構築してくれるConstructです。執筆時点でそこまで種類はなく、大きく分けて以下の2つが提供されています。Constructを使用すると、たった数行で特定のユースケースに最適な環境をネットワーク周りも含めて構築してくれるのです。},});技術交流会では、このコードを実際にデプロイして動作させるところまで実演してみました。だいたいこんな感じの環境ができあがります。この全能感がたまりません。Constructは採用しませんでしたが、気軽にインフラ構築できるという点でAWS新規利用時や個人開発で役立ちそうだと感じたため番外編として挙げております。最後に本施策以外にも、最近の新規プロダクトではAWSの知見は必要不可欠です。2016.06に行ってきました!みなさん、こんにちは。コンテンツ・メディア第1事業部インフラ...2016-05-27テスト環境にOpenStackを導入しました!みなさん、こんにちは。6引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。