BacklogでPR(Spring F/W)があったらJenkins(AWS)がコードレビューの一部をしてくれて

jenkinsの設定をする jenkinsで各チェックが動くように設定をしていきます。 jenkinsにジョブを追加する。 1.jenkinsのダッシュボードを開く 2.新しいジョブをクリックして、適当な名前を付けて”Mavenプロジェクトのビルド”を選択する。 Git、Mavenの設定をする。 1.[jenkinsの管理]->[Global Tool Configuration]を選択する。 続きを読む

バックエンドエンジニア

【開発体制】 アジャイルな開発体制としてスクラムを採用 【開発環境】 □言語:PHP(フレームワーク:FuelPHP)□環境:Linux(AWS EC2 ), Apache □DB : MySQL□バージョン管理:Git, GitHub□メール配信 : AWS SES□画像サーバ: AWS S3□CDN : AWS CloudFront□キャッシュ : AWS ElasticCache□その他 : RDS, … 続きを読む

Ruby on Rails アプリをAWSにアップするまで

Webアプリ初心者がはじめてrailsアプリをAWSへアップするまでの作成日記
作成中のサイト
https://www.drink-app.club/

  • ID:admin
  • pass:test0108

https://github.com/katsun0921/drink-app-rb

参考サイト

@iwaseasahi さんのページを参照すればだいたいAWSへのアップはいける

はまったところ

ruby2.5.0でやったらDeviseでSyntaxErrorとなった。

バグらしいので修正が必要だった

SyntaxError: /.../devise-3.5.5/app/controllers/devise/sessions_controller.rb:5: syntax error, unexpected '{', expecting keyword_end
...ter only: [:create, :destroy] { request.env["devise.skip_tim...

ここをコードを修正

prepend_before_filter only: [:create, :destroy] { request.env["devise.skip_timeout"] = true }
prepend_before_filter(only: [:create, :destroy]) { request.env["devise.skip_timeout"] = true }

nginxでrestartが反映されない?

修正ファイルをgit hubからpull したら、反映されずというかDNSが切れた
なぜ?
どうやらnginxだとrestartではなくreloadだとうまくいく
http://abyssluke.hatenablog.com/entry/2015/12/11/203707

sudo nginx service reload

でうまくいかなかったらreload

sudo nginx -s reload

develop環境だと画像が表示されるのに、producton環境だと画像が表示されなくなった?

ローカル環境でのvagrantだと画像は、表示されるのにAWSにアップしたら表示されない?
assets/images 配下に画像をおいていた

background: url(/assets/images/hoge.jpg)

この書き方だとパスの書き方が間違っていたっぽい

https://qiita.com/wadako111/items/03bc00d914e62243a511

このページを参考にして画像をpublicへ変更したら解決

/public/images/

に画像をおいて画像パスを変更

background: url(/images/images/hoge.jpg)

assetsにあるcssは変更したらプリコンパイルを忘れず

bundle exec rake assets:precompile RAILS_ENV=production

続きを読む

CodeDeployでGitHubのソースをEC2にデプロイするまとめ

AWSが用意してくれているドキュメントがところどころ分かりにくかったのでざっくりとまとめ。コンソールの操作です。

用意するもの

  • EC2インスタンス
  • GitHubにレポジトリ

インスタンスにタグをつける

デプロイ先のEC2インスタンスをタグで管理します。デプロイ実行するときに、ここでつけるタグを指定することでデプロイ先を選択することになります。

EC2コンソールの左メニューから「インスタンス」>「アクション」>「インスタンスの設定」>「タグの追加/編集」
codedeploy1.png

適当にキーと値を設定します。インスタンスを管理しやすい形でWEBサーバーとかAPサーバーとかで設定するのもよし、新機能検証やパフォーマンステストなどの目的別に設定するのもよし。スクショは今回のインスタンスでLINEのAPIをテストしたかったのでPurpose=LineTestなるタグを設定してますが、まあなんでもOK。
codedeploy2.png

ロールを割り当て

IAMコンソールからからAmazonS3ReadOnlyAccessとAWSCodeDeployRoleを追加
codedeploy3.png

AmazonS3ReadOnlyAccess

CodeDeployエージェントをEC2インスタンスにインストールするときS3バケットからパッケージを持ってくるのでこのロールが必要。「AWSサービス」>「EC2」>「EC2」を選んで次のステップをポチ。
スクリーンショット 2018-02-03 10.png

次のページでAmazonS3ReadOnlyAccessを選んで適当にロール名を入れてロールを作成。

AWSCodeDeployRole

CodeDeployの実行ロールを作成。②のところでEC2を選んでもCodeDeployのロールが作成できたんですが、EC2ではデプロイできませんでした。②のところではCodeDeployを選択します。
スクリーンショット 2018-02-04 9.png

次の画面でははそのまま「次のステップ」、その次の画面でロール名をつけてロールを作成。

CodeDeployの設定

CodeDeployエージェントをEC2インスタンスにインストールし、CodeDeployコンソールからデプロイするアプリケーションを作成します。

EC2インスタンスにCodeDeployエージェントをインストール

# この辺はすでにインストールされてるかと思いますが
sudo yum update
sudo yum install ruby
sudo yum install wget

# ディレクトリはどこでもいいとは思いますがドキュメントに沿って
cd /home/ec2-user

# CodeDeployエージェント
wget https://aws-codedeploy-ap-northeast-1.s3.amazonaws.com/latest/install
chmod +x ./install
sudo ./install auto

# 実行
sudo service codedeploy-agent start

こちらのドキュメントにはwget https://bucket-name.s3.amazonaws.com/latest/installと書いており、下の方にbucket-nameを該当リージョンに変更するようにとありますので、東京の場合はaws-codedeploy-ap-northeast-1に書き換えます。

アプリケーションを作成

CodeDeployのコンソールから「アプリケーションの作成」をクリックし作成画面に移動。

FireShot Capture 1 - AWS CodeDeploy_ - https___ap-northeast-1.png
アプリケーション名、デプロイグループ名は適当に。
環境設定のタグのところで前述したタグを設定する。
詳細設定のサービスロールでAWSCodeDeployRoleのロールを選択し「アプリケーションの作成」を押して作成完了。

デプロイ実行

いよいよ最後になります。CodeDeployのメニューから「デプロイ」を選択、デプロイ画面で「デプロイの作成」から作成画面に移ります。

FireShot Capture 2 - AWS CodeDeploy_ - https___ap-northeast-1.png
アプリケーション名とデプロイグループはアプリケーションの作成で設定した名前を選択。
リポジトリタイプはGitHubを選択しGitHubアカウントとレポジトリ名、それからデプロイしたいコミットのハッシュを入力し「デプロイ」をクリック。
これでGitHubからソースのデプロイが完了。

まとめ

この程度ならEC2インスタンスからgit pullすればできちゃいますが、複数のインスタンスを管理するとなるとCodeDeployを使うメリットは大きいです。今回は基本的な設定をまとめてみましたが、デプロイの自動タスク化なんかもできて便利そうです。その辺も今後触ってみて、またまとめておきたいと思います。

続きを読む

keystoneJSをnginxでデプロイしてaws上で動かす。

wordpressが使いたくなく、python大好きマンなのでmezzanineを使おうと思ったのですが、デプロイで頓挫したのでnodeJSでやろう。keystoneJSでやろうという次第です。

DDNSにはno-IPを利用しました。

keystoneJS official

前提

  • awsにインスタンスを作成済み
  • 上記インスタンスの3000番ポートを開けておく
  • 上記のインスタンスにssh接続出来る

諸々のインストール

sudo yum update -y

nodeJS


curl -L git.io/nodebrew | perl - setup
echo 'export PATH=$HOME/.nodebrew/current/bin:$PATH' >> ~/.bash_profile
ebisennet$ source ~/.bash_profile

nodebrew install-binary v9.4.0

mongoDB

こちらの記事を参考にさせて頂きました。

sudo vim /etc/yum.repos.d/mongodb-org-3.2.repo

[mongodb-org-3.2]
name=MongoDB Repository
baseurl=https://repo.mongodb.org/yum/amazon/2013.03/mongodb-org/3.2/x86_64/
gpgcheck=1
enabled=1
gpgkey=https://www.mongodb.org/static/pgp/server-3.2.asc

sudo yum install -y mongodb-org

sudo service mongod start

sudo chkconfig mongod on

Yoeman

sudo npm install --global yo

keystoneJS

sudo npm install -g generator-keystone

no-IP

sudo yum-config-manager --enable epel
sudo yum install -y noip

nginx

sudo yum install nginx

forever

npm install -g forever

keystoneJSの実行

公式ページの通りに進めます。
htmlはpug,cssはsassがオススメです。

mkdir my-test-project
cd my-test-project
yo keystone

node keystone

この時点で[myIP]の3000ポートにアクセスするとページが見れるはずです。
example : http://x.x.x.x:3000

no-IPの設定

awsのドキュメントを参考に進めます。

sudo noip2 -C
sudo chkconfig noip on
sudo service noip start

nginxでデプロイ

sudo vi /etc/nginx/nginx.conf
nginx.conf
    #keepalive_timeout  0;
    keepalive_timeout  65;

    #gzip  on;

    include /etc/nginx/conf.d/*.conf; #この一行だけ加える
    ...
sudo vi /etc/nginx/conf.d/keystone.conf
keystone.conf
upstream node-sampleapp1 {
    server localhost:3000;
}

server {
    listen       80;
    server_name  http://DNSNAME/;
    proxy_redirect                          off;
    proxy_set_header Host                   $host;
    proxy_set_header X-Real-IP              $remote_addr;
    proxy_set_header X-Forwarded-Host       $host;
    proxy_set_header X-Forwarded-Server     $host;
    proxy_set_header X-Forwarded-For        $proxy_add_x_forwarded_for;
    location / {
        proxy_pass http://node-sampleapp/;
    }
    error_page   500 502 503 504  /50x.html;
    location = /50x.html {
    root   /usr/share/nginx/html;
    }
}

foreverでデーモン化

forever start keystone.js

デバックモードを切る

vi my-test-project/.env

NODE_ENV=productionとする。

あとは、templatesやpublic,routesなどを編集して自分好みのスタイルに変更する。
また、記事の投稿はhttp://DNSNAME/keystone/signin より行う。

オチ

markdownのプラグインとか欲しいのでwordpressを始めようと思いました。

続きを読む

copy files from local to aws S3 Bucket(aws cli + s3 bucket)

                       **AWS CLI and S3 Bucket**

maxresdefault.jpg

In my current project, I need to deploy/copy my front-end code into AWS S3 bucket. But I do not know how to perform it. One of my colleagues found a way to perform this task.

here are the guidelines from start to end, how to install aws cli, how to use aws cli and other functionalities.

So, let’s start from the beginning.
In my mac, I do not installed aws cli, so I got the error when running the following command.
Open your terminal,

$ aws --version

output
-bash: aws: command not found

(Here I got the solution, https://qiita.com/maimai-swap/items/999eb69b7a4420d6ab64)

So now let’s install the brew, if you do not installed yet.
Step1. Install the brew

$ ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

Step2. check the brew version

$ brew -v

output
Homebrew 1.5.2
Homebrew/homebrew-core (git revision 58b9f; last commit 2018-01-24)

Step3. install aws cli, use the following command

$ brew install awscli

Step4. check the aws cli version

$ aws --version

output
aws-cli/1.14.30 Python/3.6.4 Darwin/17.3.0 botocore/1.8.34

that’s great, now it’s time to configure the AWS credential.
Step5. now configure the aws profile

$ aws configure
AWS Access Key ID [None]: <your access key>
AWS Secret Access Key [None]: <your secret key>
Default region name [None]: <your region name>
Default output format [None]: ENTER

All settings are done.
now you can access your s3 bucket.

now from here, we can learn how to manage our bucket.
Managing Buckets
aws s3 commands support commonly used bucket operations, such as creating, removing, and listing buckets.

1.Listing Buckets

$ aws s3 ls

output
2017-12-29 08:26:08 my-bucket1
2017-11-28 18:45:47 my-bucket2

The following command lists the objects in bucket-name/path (in other words, objects in bucket-name filtered by the prefix path/).

$ aws s3 ls s3://bucket-name

2.Creating Buckets

$ aws s3 mb s3://bucket-name

(aws s3 mb command to create a new bucket. Bucket names must be unique.)

3.Removing Buckets
To remove a bucket, use the aws s3 rb command.

$ aws s3 rb s3://bucket-name

By default, the bucket must be empty for the operation to succeed. To remove a non-empty bucket, you need to include the –force option.

$ aws s3 rb s3://bucket-name --force

This will first delete all objects and subfolders in the bucket and then remove the bucket.

Managing Objects
The high-level aws s3 commands make it convenient to manage Amazon S3 objects as well. The object commands include aws s3 cp, aws s3 ls, aws s3 mv, aws s3 rm, and sync. The cp, ls, mv, and rm commands work similarly to their Unix

The cp, mv, and sync commands include a –grants option that can be used to grant permissions on the object to specified users or groups. You set the –grants option to a list of permissions using the following syntax:

--grants Permission=Grantee_Type=Grantee_ID
         [Permission=Grantee_Type=Grantee_ID ...]

Each value contains the following elements:
* Permission – Specifies the granted permissions, and can be set to read, readacl, writeacl, or full.
* Grantee_Type – Specifies how the grantee is to be identified, and can be set to uri, email address, or id.
* Grantee_ID – Specifies the grantee based on Grantee_Type.
* uri – The group’s URI. For more information, see Who Is a Grantee?
* email address – The account’s email address.
* id – The account’s canonical ID.

aws s3 cp file.txt s3://my-bucket/ --grants read=uri=http://acs.amazonaws.com/groups/global/AllUsers full=emailaddress=user@example.com

For more details, please go through the aws official link.
https://docs.aws.amazon.com/cli/latest/userguide/using-s3-commands.html

thank you for taking your precious time to read.

Enjoy coding.:grinning::grinning:

Thanks & Best Regards,
Alok Rawat

続きを読む

【イベントレポート】JavaプログラマのためのAWSサーバーレスハンズオン-ServerlessFrameworkで画像処理アプリケーションを構築編-

本記事は、
弊社株式会社スタイルズで開催したJavaプログラマのためのAWSサーバーレスハンズオン-ServerlessFrameworkで画像処理アプリケーションを構築編-(2018/1/19)のイベントレポートです。

20180119_01.png

スタイルズでは定期的にビジネスセミナーを開催しているのですが、技術イベントは久しぶりの開催となりました。
2018年はもっと技術イベントも主催したいという意味も込めて、2018年の主催イベント一発目はAWSサーバーレスのテーマでハンズオンを企画いたしました。

当日は定員ぴったりの満席!

Doorkeeperでの受付開始直後に20名の定員となってしまったので、当日にご都合が悪くなられて、来場できない方もいるかな。。。
と心配していたのですが、受付開始時間から、お申込みいただいた皆様にお越しいただき。。。

なんと定員ぴったり20名(+1名)の方にお越しいただきました!!
(1名の方はキャンセル待ちの状態だったのですが、直接会場にお越しいただきました!感激です)

20180119_02.png

Gitの画面を見ながらハンズオン

挨拶、サーバーレスの説明もそこそこに、参加者の皆様をGitにinviteして、Gitの画面を見ながらハンズオンをすすめさせていただきました!

事前にご案内をしていた以下のインストールとGitMavenのインストールを確認して、ハンズオンを開始!

  • ServerlessFramework(>= 1.23.0)のインストール
  • AWS CLIのインストール

今回のハンズオンでは、AWS IAMを個々にご案内させていただきました。

20180119_03.png

ハンズオンの概要

  • awslabsのaws-serverless-workshopsを参考に、サーバーレス画像処理アプリケーションの構築ハンズオン

  • アーキテクチャは、Amazon Rekognitionの顔検出機能を活用し、- Amazon S3に格納されているアップロードされた画像のリサイズ、Amazon DynamoDBを使用して画像のメタデータをユーザープロファイルに保存する、いくつかのAWS Lambda関数で構成。これらのLambda関数のオーケストレーションは、AWS Step Functionsステートマシンによって管理。

  • 各AWS Lambda関数はSpringCloudフレームワークにより実装。各AWS Lambda関数及び、AWS Step FunctionsステートマシンはServerless FrameworkにてDeploy。

20180119_04.png

感想と反省・今後に向け

アンケートで分かる範囲ですが、今回ご参加いただいた方は6割強が設計・開発職、4割弱が運用・監視などのインフラ職でした。
AWSサーバーレスというキーワードだと、やはりインフラエンジニアの方への訴求も強いのですね。

また、今回は、Serverless Frameworkの説明や、本構成における個々のサービスがどのような役割をになっているのかを駆け足で説明してしまったところがあったので、
今後は、上中下のような形で、もう少し丁寧に解説するという初級ハンズオン、逆に参加者にご参加いただきながらどんどん開発を進めていく上級ハンズオン(趣味のコミュニティみたいなイメージでGitで開発を進めるとか?)なんかがあっても良いのかな。と個人的には感じています。

2018年はデジタルトランスフォーメーションのための開発サービスがテーマ

スタイルズでは、今回のようなサーバーレス、コンテナーによるDevOps、IoTプラットフォームを利用したPoCなど、技術要素をいかにエンタープライズに適用していくのか?というテーマで、
2018年は多数ハンズオンイベントを企画していければと思っています。

インフラはAWSが基本になってくると思いますが、もしAWS×Devのテーマで聞きたいことや現在直面しているテーマなどがございましたら、
ぜひぜひご意見をお待ちしております!!

最後に

本ハンズオンの企画にあたりStep Functionsに関しては以下の記事を参考にさせていただきました。大変勉強になる記事をありがとうございます。

また、本ハンズオンで講師を担当したスタイルズ社員もServerless Frameworkに関してQiitaで発信をしています。
ご参考までにご覧ください。

続きを読む

27円/月で運用できるAWS Lambda を用いたウェブサイトの外形監視

ウェブサイトの外形監視とは?

 ウェブサイトがユーザーからきちんと閲覧できるかどうかを監視するという至極単純なものが「ウェブサイトの外形監視」です。外形というワードが入っているとおり、ユーザー側から名前解決を正常に行うことができ、宛先にきちんとリクエストを行え、妥当な時間内に正常なレスポンスを受け取ることができるかをチェックすることが目的になると思います。

 したがって、構築されたサーバーとはネットワーク的にも物理的にも独立した場所から監視を行えると良いのですが、そうすると外形監視サーバーのお守りをしなければならず、個人でちゃんとやろうとすると微妙に面倒ではあります。

AWS Lambda を用いたウェブサイトの外形監視

 AWS Lambda は、オンデマンドでコードの断片を実行することができるアプリケーション基盤です。あらかじめサーバーを立てて置かなくても、実行したいコードを配置しておき、実行したいときにサーバーのことなど何も考えずに呼び出すことができます。ウェブサイトの外形監視は、せいぜいリクエストを送ってステータスコードやレスポンスタイムなどを見てあげるだけの簡単な処理であるため、相性がよさそうです。

 サービスを AWS 以外のクラウドや、オンプレミスで運用している場合には物理・ネットワーク的に異なる条件から対象を監視することができます。また、AWS Lambda は複数のリージョンにデプロイすることが可能なため、AWSを利用している場合でも、世界中の様々なリージョンを利用することにより、地理的に異なる場所から対象を監視することが可能です。

 AWS には Route 53 にすでにヘルスチェッカーが存在しているのですが、色々なオプションをちまちまつけていくと少しずつお金を取られていくので(といっても大した額ではないんですが…)、 #okane_nai 勢の私は AWS Lambda の無料利用枠で同じようなことが実現できるのではないかと思い、今回試してみることにしました。

システムの全体像

 AWS Lambda の実行トリガーはイベントソースと呼ばれています。外形監視のイベントソースとしては定期的に実行できる cron のような振る舞いを実現できればよさそうです。AWS CloudWatch Events がちょうどそのようなものに該当しており、cron 式や rate 式によって以下のように簡単にイベント発行のスケジューリングが可能です。

lambda_health_check_01.png

 単純な外形監視の通知先として Slack への通知を考えるとするならば、最小構成としての AWS Lambda と AWS CloudWatch Events を用いた仕組みの全体像と稼働のイメージは以下のような図になります。

lambda_health_check_02.png

 AWS Lambda で動くコードは、自由にカスタマイズできる普通のコードですので、たとえば Twillio API と連携して異常検知時に電話を鳴らしたり、レスポンスに特定の文字列が含まれているかチェックしたりなど様々なことができます。また、Amazon SNS を利用して様々な通知連携を行ったり、DynamoDB などを用いて監視データを蓄積したりすることも可能です。個人でお遊び監視を入れるには監視サーバーをお守りする必要もなく、楽しいおもちゃになるのではないでしょうか。

AWS Lambda を用いた外形監視のコスト見積もり

2018年1月現在、AWS Lambda には以下のような無料枠が設けられています。

  • リクエスト: 月間 1,000,000 件
  • コンピューティング時間: 月間 400,000 GB-秒

したがって、リクエスト数とコンピューティング時間の2つの軸でコストを見積もる必要があります。

また AWS CloudWatch Events については単純に発行するイベント数に応じて課金がなされます。

AWS Lambda リクエスト数の見積もり

 毎分ヘルスチェックをまわすとすれば、 1 (req) * 60 (min) * 24 (hour) * 31 (day) = 44,640 (reqest) となり、無料利用枠の中に余裕を持っておさまります。もし他の用途で無料利用枠を使い切っているとすれば、課金額は 44,640 (request) * 0.0000002 (USD/request) = 0.008928 (USD) となります。

AWS Lambda コンピューティング時間の見積もり

 node.js で動く HTTP リクエストを送る単純なプログラムであるため割り当てメモリは一番小さな 128MB (= 1/8 GB) で十分です。手元で稼働させている実績からほぼ 1000ms 以内にヘルスチェックが完了しているのですが、バッファをとって平均 2000ms かかると仮定して計算するならば、 1/8 (GB) * 2 (sec) * 60 (min) * 24 (hour) * 31 (day) = 11,160 (GB-sec) となり、無料利用枠におさまります。もし他の用途で無料利用枠を使い切っているとすれば、課金額は 11,160 (GB-sec) * 0.00001667 (USD) = 0.1935387 (USD) となります。

AWS CloudWatch Events の見積もり

 AWS CloudWatch Events は $1.00/100万イベントという料金になっているため、単純に 1 (event) * 60 (min) * 24 (hour) * 31 (day) = 44,640 (event) / 1000000 (event/USD) = 0.04464 (USD) のお金が必要です。

総費用の見積もり

 無料利用枠を使っていないのであれば、AWS Lambda の費用はすべて枠内におさまっており、無料で稼働中のサーバーとは地理的に異なる場所に配置できる外形監視を導入することができます。また仮に無料利用枠を使い切っているとしても、0.008928 + 0.1925387 + 0.04464 = 0.24610677 (USD) の課金が発生します。多分 27 円くらい取られます。 お財布には厳しいですが、気合いです。

外形監視のための AWS Lambda 関数の作成

 作るものは非常に単純で、node.js で HTTP リクエストをサーバーに送り、ステータスコードが 200 番台だったらオッケーで、その他の場合は Slack の incomming webhook を利用してメンションを飛ばすだけです。Slack の設定次第では、スマホにプッシュ通知とか飛ばせるので、面倒なこと考えずに手軽に検知手段が欲しいときにこの方法はコスパが良いのではないでしょうか。

 コードなどどうでもいいので、いますぐ試してみたいという方のために、簡単にデプロイできるような形にしておきましたので、こちらの GitHub リポジトリ1 からクローンしてみてください。数ステップで AWS Lambda 上にデプロイしてお試しいただけます。

基本的なコード

 暇人の趣味なので FlowType を使ってます。request を使ってリクエストを送って、ステータスコード見てるだけなので、基本的には以下のような簡単なコードを書いてアレコレしていくだけです。

// @flow

import request from 'request-promise-native';

async getStatus(): Promise<Object> {
   const options = {
     method: 'GET',
     uri: 'https://exapmle.com',
     timeout: 3000,
     headers: {
       'User-Agent': 'Mozilla/5.0 (Oreore Health Checker;)'
     },
     resolveWithFullResponse: true
   };
   try {
     const { statusCode, statusMessage } = await request(options);
     return { statusCode, statusMessage };
   } catch (err) {
     console.log(JSON.stringify(err));
     if (err.response) {
       const statusCode = err.response.statusCode;
       const statusMessage = err.response.statusMessage;
       return { statusCode, statusMessage };
     } else {
       const statusCode = null;
       const statusMessage = err.message;
       return { statusCode, statusMessage };
     }
   }
 }

 ラムダ関数 1つで複数サイトの監視をさせるために、設定ファイルに書いた URL リストを舐めて、それぞれに対して上記のような関数を呼び出し、サービスの状態を並列に確認させています。このような仕組みで、現状手元で 10 エンドポイントくらいを監視させていますが、関数の実行時間はそれほどかわらず、結果としてはレスポンスが一番遅いエンドポイントに引きずられているような挙動に見えます。

Apex を使った AWS Lambda 関数の管理

 AWS Lambda 関数のデプロイをマネジメントコンソールからやるのは面倒なので、Serverless とか Apex などを使うと良いと思います。今回は簡単なものだったので、Apex を利用しました。適切な設定をすると次のようなワンコマンドで、AWS Lambda にデプロイすることができます。

apex deploy

ためしにデプロイした関数を実行したいときも次のようにとてもお手軽です。

apex invoke (関数名)

成果物を俺にも使わせろ

 どうぞどうぞ。こちらの GitHub リポジトリからクローンしてください。使うまでには次のような作業をしてください。

  1. 必要なもの(aws-cli, apex)をインストール
  2. git clone git@github.com:53ningen/sousie.git && cd sousie
  3. マネジメントコンソールからラムダ関数が使う IAM ロールを作る
    • 詳しくはこのあたりの資料を見てください
    • AWS CloudWatch ログ書き込み権限をアタッチする
  4. cp ./project.json.template ./project.json して role の欄に作った IAM Role の ARN を書く
  5. cp ./config.json.template ./config.json して ヘルスチェックしたいエンドポイントや Slack の設定などを行う
  6. apex deploy
  7. AWS CloudWatch Events をマネジメントコンソールから設定して、デプロイした AWS Lambda 関数が定期実行されるようにする

 今後は CLI ベースのセットアップ用ツールの作成、Amazon SNS トピックへの通知や、DynamoDB との連携によるリッチな通知閾値設定、CloudWatch カスタムメトリクスとの連携機能などを実装するつもりです。飽きなければ…。あと基本的に JavaScript 素人なのでおかしなところあったら修正 pull request いただけると嬉しみ〜という感じです。

まとめと展望

  • AWS Lambda を使うと非常に安価に外形監視を行うことができます
  • 個人運用のサービスなどではこのレベルでも十分に役に立つ監視基盤となりうるのではと思います
  • ただの簡単な JavaScript コードであるため複雑なカスタマイズも自由にできます
    • Twillio などを使えば電話も鳴らせます
    • カスタマイズすれば、状況によってなんらかのオペレーションをするみたいな自動復旧の仕組みとかも仕込めそう
  • Amazon CloudWatch カスタムメトリクスや Amazon SNS, AWS Step Functions などと連携すればかなり複雑なこともできるのではないかと思います
  • AWS の無料利用枠を使って快適な人生を送ろう

 あとここまで書いておいてアレなんですが、自分の個人サービスの一部、Route 53 の DNS フェイルオーバー設定入れているので、結局 Route 53 のヘルスチェック使ってます。

Special Thanks

 わたしは JavaScript 素人なので、このまわりのよくわからないことに関しては @nagisio 大先生にご指導いただきました。本当にありがとうございます。


  1. リポジトリの名前は「異世界はスマートフォンとともに。」のキャラクターである、スゥシィ・エルネア・オルトリンデ(CV: 山下七海)様の名前をお借りしました 

続きを読む