AWS Sandbox環境とServerless Frameworkのお話 - ハウテレビジョンブログ

はじめに

ハウテレビジョンでソフトウェアエンジニアをやっている山本と申します。
弊社ではインフラエンジニア以外でも、AWSを扱えるようになることを目的とし、エンジニア全員にAWSのSandbox環境が用意されています。今回はこのAWSのSandbox環境とServerless Frameworkを利用して、お手軽にAWS LambdaとSlack botの検証環境を作ったお話です。

AWS Sandbox環境について

まずAWS Sandboxについてです。これは弊社においてAWSの習熟や検証を目的として用意された環境で、エンジニア一人ひとりに用意されています。

検証環境といえば部門やチーム単位で用意されてることがあるかもしれません。弊社でもSandboxとは別に共用の検証環境はございます。しかし、共用であるがゆえに使用する際には他のメンバーへの周知や調整が必要となります。

「もっと気軽にAWSでアプリのデプロイしたい」「このAWSサービス構成でいけるかちょっと試したい」「なんならAWSの学習にも使いたい」というケースにおいてSandbox環境が使われています。

Serverless Framework

Serverless Frameworkは、クラウド上でサーバーレスアプリケーションを構築、デプロイ、管理するためのオープンソースのツールです。
開発者は、サーバーやインフラストラクチャの管理に心を配ることなく、コードに焦点を当てることができます。Serverless Frameworkは異なるクラウドプロバイダ（AWS、Azure、Google Cloudなど）と統合し、イベントドリブンなアーキテクチャの構築を容易にします。これにより、コストの最適化とアプリケーションの柔軟性が向上します。

www.serverless.com

やってみた

今回のイメージはこんな感じです。
Slack→AWS API Gateway → Lambda（aws-serveless-express + 実装した関数）→ Slack

Serverless Framework インストール

まずはServerless Frameworkをインストールします。
公式の手順はこちら。

Lambda関数

次にLambda関数を実装します。
今回は例としてSlackに"hello"と投稿されたら、"Hi."を返すだけの簡単なものをNode.jsで実装しました。 Slackとの連携はSlack-boltを利用しています。

const { App, ExpressReceiver } = require("@slack/bolt");
const expressReceiver = new ExpressReceiver({
    signingSecret: process.env.SLACK_SIGNING_SECRET,
    processBeforeResponse: true,
});

const app = new App({
    logLevel: LogLevel.DEBUG,
    token: process.env.SLACK_BOT_TOKEN,
    receiver: expressReceiver,
    processBeforeResponse: true,
});

app.message(/^(hello)$/i, async ({ say }) => {
    await say("Hi.");
});

デプロイ設定

公式を参考にしてserverless.ymlに記述します。
※設定値は別ファイルに定義してあります。stageオプションでsandboxを指定するとsandbox.ymlが読み込まれます。

service: slack-hi
frameworkVersion: "3"

plugins:
  - serverless-better-credentials

custom:
  defaultStage: sandbox
  env: ${file(./env/${self:provider.stage}.yml)}
provider:
  name: aws
  lambdaHashingVersion: 20201221
  runtime: nodejs18.x
  region: ${self:custom.env.REGION}
  stage: ${opt:stage, self:custom.defaultStage}
  environment:
    REGION: ${self:custom.env.REGION}
    SLACK_SIGNING_SECRET: ${self:custom.env.SLACK_SIGNING_SECRET}
    SLACK_BOT_TOKEN: ${self:custom.env.SLACK_BOT_TOKEN}
    SLACK_CHANNEL_ID: ${self:custom.env.SLACK_CHANNEL_ID}
    SLACK_WEBHOOK_URL: ${self:custom.env.SLACK_WEBHOOK_URL}

ここでちょっと小ネタなのですが、デプロイするためにはAWSのAccssKeyとSecretが必要になります。

しかしAWS Single Sign On (AWS SSO) を設定してある場合、serverless-better-credentialsプラグインを使うことでSSOで認証できるようになります。設定は簡単で、インストールしたあとにserverless.ymlのpluginsに追加するだけです。

service: slack-hi
frameworkVersion: "3"

plugins:
  - serverless-better-credentials

参考記事：https://zenn.dev/snowcait/articles/9d770774a655a5

デプロイ実行

コンソールから以下のコマンドを実行。
--stageでsandbox用のymlを指定 --aws-profile で AWS SSOのprofileを指定

serverless deploy --stage sandbox --aws-profile sandbox-sso

ブラウザが起動し、AWS SSOの認証を求められるので承認します。

認証が成功すると、AWS Lambdaにデプロイされます。

実際にはCloudformationでサービスが構成されるので、想定と違う構成になっている場合は.serverless配下のcloudformationのjsonファイルを見ると、どのような設定が反映されているのかを確認できます。

あとはSlackAppの設定で必要な権限とEvent SubscriptionsのRequestURLにAPI GatewayのEndpointを指定すると、SlackとLambdaの連携が完了です。

終わりに

個人に割り当てられたAWS Sandbox環境があると、気兼ねなく技術検証や動作確認がおこなえるのでオススメです。
しかし、いきなりAWSの環境を個人に与えるのは、セキュリティや予算の問題があると思います。弊社ではSandboxの導入時に有識者による講習会やハンズオンを実施して、必要な知識を得た状態でスタートしました。

フロントエンドエンジニアやバックエンドエンジニアであっても、インフラの知識は必要になってきています。
自ら実装したアプリやツールを実際にAWSにデプロイして動かしてみるというのは、インフラの学習面においても良い影響を与えていると思います。