【AWS】サーバーレスで問い合わせフォーム (s3,Lambda,SES)

はじめに

AWSome Day(awsのセミナー)に参加しまして、
学習意欲が湧いたので、早速、サーバーレスで
お問い合わせフォーム有りのウェブサイト製作をしてみました。

Amazon Web Service初めて使ってみました。
備忘録としてまとめます。

やりたいこと洗い出し

  • 静的なWebサイトホスティング
  • お問い合わせ機能
  • 問い合わせの通知 ⇨ 私 & 担当者
  • SSL化

使ったサービス

  • Route53
  • Cloudfront
  • ACM (AWS Certificate Manager)
  • s3 (Simple Strage Service)
  • Cognito
  • Lambda
  • SES (Simple Email Service)

それぞれのサービスの説明は、
こちらの記事が簡潔で分かりやすいです!
「AWS is 何」を3行でまとめてみるよ

構成図

aws_Diagram_.png

進め方

正直、初めてAWSを触るということもあり、
どこから手をつければ良いのか分かりませんでした..
なんとなく機能を分割して手をつけていきました。

  • 0. 静的サイト制作
  • 1. s3からs3にput、Cognito認証
  • 2. Lambda、SES
  • 3. Route 53
  • 4. CloudFront,ACMの設定

こちらの記事、大変参考にさせて頂きました。
初心者にも分かりやすく、助かりました。

詳細

メモレベルですが、やったことを残しておきます。

① s3 / Cognito

aws_Diagram (3) (2).png

上記サイトのjsを参照し、s3からs3にputできるようにしました。

やったこと
  • s3 バケット作成、html,css,img,js配置
  • Cognito IAM独自のポリシーを作成を作成し、アタッチ。Acctionでputを追加し、s3バケット名を指定するだけで大丈夫です。
  • ACLのデフォルトは”public-read”なので、明示的に”authenticated-read”とかに設定する必要があります。
  • CROS設定で、alloworiginを設定する必要があったのですが、Route53の設定をまだしてなかったので、後回しにしました。

② SES / Lambda

aws_Diagram (_3).png

まず、SESのメール認証を行います。

  • SES ⇨ Email Addresses ⇨ Verify a New Email Address
    自分のメールアドレスを入力し、申請するとメールが届くのでリンクを押せば完了です。

  • ①でs3からs3にput出来るようになったので、そのイベントをトリガーにLambdaの設定を行います。
    こちらのサイトのjsをほぼそのまま使わせて頂きました。

  • IAMロールは、AmazonSESFullAccessを付与します。

③ Route53

お名前.comで既にドメイン購入済みでした。
AWSで発行したNSレコードを、お名前.comの方に追加する必要がありました。手順をこちらにまとめたので参考にして頂ければ幸いです。
【Route 53】【お名前.com】【Amazon S3】Webサイト作成

④ CloudFront / ACM

大変参考にさせて頂きました。

ACM

  • 2017年10月より、DNS認証が追加され、設定が簡単になりました。またワイルドカード証明書も無料で発行できるので、CloudFront使う際は使っておきたいですね。
  • 適応されたらCloudFront側で、http to https設定を行います。

  • 設定完了後、s3のCROS設定に、下記を追加します。
    <alloworigin>https://www.ドメイン.com</alloworigin>

まとめ / 反省点

設定項目が多すぎて、何をどこまで設定するべきなのか難しい。使った分だけ課金されてしまうこともあり、ちゃんと把握しておきたい。

続きを読む

Athenaで入れ子のjsonにクエリを投げる方法が分かりづらかったので整理する

Kinesis FirehoseでS3に置かれた圧縮したjsonファイルを、それに対してクエリを投げる、というのを検証してたのですが、Hive素人なのでスキーマの作り方もクエリの投げ方も正直あんまり良くわかってませんでした。

そこで下記を参照しながらスキーマの作成とクエリ投入をやってみて、最終的にうまくいきました。

日本語記事
https://aws.amazon.com/jp/blogs/news/create-tables-in-amazon-athena-from-nested-json-and-mappings-using-jsonserde/

元記事
https://aws.amazon.com/jp/blogs/big-data/create-tables-in-amazon-athena-from-nested-json-and-mappings-using-jsonserde/

ずーっと日本語記事を読みながらやっていたのですが、これがめちゃくちゃわかりづらい!!!
※理解度には個人差があります

多分知っている人が見たら何となくわかるんでしょうが、恐らくこれを見るのは自分みたいにあまり良く知らないので参考にしながら実際にやってみている、という層だと思います。
最終的に上手く行ってから思ったのは、前提知識がないと読むのがしんどい、ということですね…。
ただもう少し書いといてくれるだけで十分なのに…。
原文も軽く見ましたが、そっちにも書いてないのでそもそも記述されてません。

調べてもまだ中々情報が出てこない上に、クエリ投入時にエラーが出た場合もエラーメッセージが淡白すぎてどこが問題でエラーになってるのかさっぱりわからなくて悪戦苦闘してました。

そんなわけで、今後同じところで困る人が一人でも減るように、自分用メモも兼ねてハマったところについて補足をしておきたいと思います。

概要

リンク先で書いてあることの流れは大まかに下記のとおりです。

  1. FirehoseでSESの送信イベントログをS3に保存する
    送信イベントログはjson形式で、それをFirehoseでS3に保存しています。
  2. Athenaのテーブルを作成して、クエリを投げる
    • ただテーブル作成して投げる場合
    • 入れ子になっているjsonに対してテーブル作成してクエリを投げる場合
    • 禁止文字を含んでいるものに対してテーブルを作成してクエリを投げる場合
      わかりづらいですが、禁止文字を含む項目をマッピングする項目とクエリを投げる項目が分かれています。)
  3. hive-json-schemaの紹介
    jsonからテーブル作成のためのクエリを生成するツールっぽいのですが、紹介してるわりにちっとも使い方が書いてません…。
    使い方の解説をどなたか…。

ハマったところ

入れ子になったjsonに対するテーブル作成について

ハマったところといいつつ、自分はこの辺は割とスムーズに行ったのですが、ちょっとわかりづらいかもしれないので念のため。
サンプルにもありますが、jsonの中にまたjsonとか配列とかが入っている、みたいなケースは多くあります。
そういった場合、内部にあるjsonに対してstruct型を使って、その下の項目について型を定義してやればOKです。
その中にさらにjsonがある場合はさらにその中にstruct型で定義をすればOK。
例にあるものだと、内部にmail{~}とjsonがあり、その中にさらにいくつかのjsonがあるので、それぞれに対してstruct型で定義をしています。
以下引用(全文は貼っていないので、元はリンク先を見てください。)
※一部バッククオート(`)で囲われている項目がありますが、予約語として使われている言葉をそのまま使用するとエラーになるそうです。
そのため、バッククオートで囲うことによってエスケープしてるようです。

抜粋した入れ子の部分
 mail struct<`timestamp`:string,
              source:string,
              sourceArn:string,
              sendingAccountId:string,
              messageId:string,
              destination:string,
              headersTruncated:boolean,
              headers:array<struct<name:string,value:string>>,
              commonHeaders:struct<`from`:array<string>,to:array<string>,messageId:string,subject:string>
              > 

禁止文字そのものについて

まず、禁止文字が色々あることを最初大して理解してませんでした。
項目名(↑の例だと、timestampとかsourceとかのところ)の定義に使用できない文字があります。
記事中だと「:」(コロン)が禁止文字列なので、それがクエリ中の該当箇所に入っているとエラーになります。
あとは「-」(ハイフン)なんかも禁止文字のようです。
例えばHTTPリクエストのログを見たとき、ヘッダとかはハイフンを使った項目がいくつもあったりするので困りますよね。
一応記事中の例では両方「_」(アンダースコア)に変換しています。(コロンにしか触れてませんが…。)
最初は禁止文字があると知らず、なぜエラーになっているかわからずにハマってました。
この辺どっかにまとまってるのかな…?
どうやって回避するかというと、それがWITH SERDEPROPERTIESの部分です。

禁止文字を含む場合のマッピングの仕方について

最初見た時はなんでこんなことをするのかわかりませんでしたが、上記の通り項目名を定義するときに禁止文字が入っているとエラーになります。
なので、WITH SERDEPROPERTIESの項目で、禁止文字列を含んだ項目名を、禁止文字列のない文字列にマッピングし、元のjsonのkeyでは禁止文字列を含んでいたものに対し、テーブル上ではカラム名として別の文字列をあてがうことができます。
記事中では、コロンやハイフンをアンダースコアに変換した文字列にマッピングしています。
式の左側がカラム名に使いたい文字列で、それに対して右側がデータの元の実際の名前です。
"mapping.カラム名に使いたい文字列"="実際の名前" みたいに記述してます。

マッピングの仕方

WITH SERDEPROPERTIES (
  "mapping.ses_configurationset"="ses:configuration-set",
  "mapping.ses_source_ip"="ses:source-ip", 
  "mapping.ses_from_domain"="ses:from-domain", 
  "mapping.ses_caller_identity"="ses:caller-identity"
  )

クエリの投げ方

これもまあおまけで書いておくと、ここまでしっかりと下の項目までテーブルを定義しておくと、下の項目までクエリで引っ張ることが出来ます。
記事中では下記のような例が出ています。

元記事にある例
SELECT eventtype as Event,
         mail.timestamp as Timestamp,
         mail.tags.ses_source_ip as SourceIP,
         mail.tags.ses_caller_identity as AuthenticatedBy,
         mail.commonHeaders."from" as FromAddress,
         mail.commonHeaders.to as ToAddress
FROM sesblog2
WHERE eventtype = 'Bounce'

mail{〜}の下の項目を参照する時は上記のようにドットをつけて該当項目の名前を指定しています。
さらにその下の項目を参照する時はその後ろにさらにドットをつけています。
この辺は直感的にわかりやすいかもしれません。

おまけとかtipsとか

Firehoseで配置されたフォルダ構成ではパーティションを自動で切ってもらえない

hiveではフォルダが/bucketname/path/to/log/year=YY/month=MM/day=dd/foo
みたいな構成だと自動でパーティション設定してくれるらしいのですが、FirehoseでS3にデータ配置すると/bucketname/path/to/log/YYYY/MM/DD/fooみたいになるので、自分でパーティションを作成する必要があります。
パーティションがない状態でクエリを投げても1件も引っかかりません。
これを作るには下記のようなクエリを投げる必要があります。

elbログを対象としたテーブルにパーティションを作成する場合
ALTER TABLE database_name.table_name
ADD PARTITION (year='2016',month='08',day='28')
location 's3://elb-access-log/AWSLogs/00000000000000/elasticloadbalancing/ap-northeast-1/2016/08/28/';

※参考
https://qiita.com/r4-keisuke/items/d3d339b76d4368b6b30a

上記の例だと1日ずつパーティションを設定する必要があるのですが、
パーティション数には上限があるらしい(1テーブル20000まで)ので、1日ずつとか、1時間ずつとかフォルダ分けしている場合はちょっと注意が必要かもしれないです。
※パーティションの上限については下記
https://docs.aws.amazon.com/ja_jp/general/latest/gr/aws_service_limits.html#limits_glue
さすがに対象が多すぎとなるとしんどいので、シェルスクリプトとかで回すといいと思います。
ただ、シェルスクリプト自体も1つ1つの処理実行だとそこそこ時間かかるのと、パーティションを設定するためのクエリでクエリ履歴が埋め尽くされるのが難点です。

データ元にない項目を定義しても値がnullになるだけで問題はない

jsonの出力が一定じゃなくて、いくつかの似たような型のjsonが混ざっていたり、ものによって存在しない項目があったりしても、それらのキーを全て網羅するようにまとめて定義しちゃって問題ないみたいです。
定義したけどデータ元に項目がない場合はnullが入るだけのようで。
逆に元データにある項目を全部定義する必要はないので、元データにあっても使わないような項目はテーブル作成の段階で定義しないようにしてもいいみたいですね。

ざっと書いたので、わかりづらいとか、もっとこうすればみたいな指摘があればいただけると嬉しいです。

続きを読む

AWS初心者がひっかりやすい制限一覧

AWSの初期設定では各サービスに制限があります

SESの検証をしていて気がついた

  • ドメイン認証さえすればよいと思っていましたが、そうではなくて初期設定のままだと受信アドレスすべて認証しないといけない
  • テストメールをgmail宛に送ったらエラーが出てなんどもpostfixの設定を見直したけどおかしなところがないので悩んだ挙句にこの制限をみつけた
  • 制限の解除は、AWSサポートに問い合わせたら1,2時間でやってくれると思います

EC2インスタンスの起動

つまるところドキュメントをちゃんと読みましょう・・・

  • 私のように何時間も無駄にしないためにも(泣)
  • AWS最強なんだけど「何でもできる感」が先行して見落としがちな制限でした

続きを読む

AWS:実業務で使えるレベルの静的Webページの環境構築をする (独自ドメイン・フォーム付き)

背景

最近の会社がそれぞれ1つは持っているであろうもの、何でしょうか?
はい、その通り。「コーポレートサイト」です。大正解です。(にっこり)
ひょんなことからコーポレートサイトのインフラ構築をAWSで行う機会があったので、その備忘録として書きます。

やったこと

正直、筆者はつい最近までAWS=EC2くらいのリテラシーの低さでした。
冷静に考えて、何もわからない…
そこでまず、ググります。GCP(Google Cloud Platform)やAzureとくらべて、ドキュメントが多いのがAWSの良いところです。

何をしたいか?(要件定義)

  • 静的なWebページのホスティングをしたい。
  • Webサイトにはお問い合わせ機能をつけたい
  • 問い合わせがあった場合、問い合わせ者に確認メールを、会社の担当者へ通知メールを送りたい
  • ドメインは新たに買う
  • www.example.com から example.com へのリダイレクト
  • ssl化もしたい

いろいろあるもんです…ただのコーポレートサイトなのに…

最終的に選択した構成

数日調べた結果、こんな感じになりました。
スクリーンショット 2017-12-14 0.34.28.png

それぞれのコンポーネントの軽い解説

Route53

ドメインの購入から管理まで、一括して行ってくれる。
サブドメインに関しても管理が可能です。
もちろん、お名前.comなどで買ったドメインをRoute53にDNS移管することもできます。

Cloud Front

AWSが提供する、CDN(Content Delivery Network)サービス。
世界中に存在するキャッシュサーバーがある特定のWebサーバーの代わりにコンテンツ配信を担ってくれます。
ここに後述するCertificate Managerで発行したSSL証明書を取り付けることで、通信のssl化が可能です。
Webサーバーが直接コンテンツ配信するのではなく、Cloud Frontが間に挟まることで、急激なアクセス増加に対してもしっかり対応できます。

S3

イレブンナインの堅牢性を誇る、AWSのストレージサービスです。
少し古いですが、このページがわかりやすいです。

https://dev.classmethod.jp/cloud/aws/cm-advent-calendar-2015-aws-re-entering-s3/

Lambda

サーバーレスでコードを実行できるコンピューティングサービス。
流行りのサーバーレスアーキテクチャの一翼です。
ただ、使える言語に縛り(2017/12/14現在、Node.js・JAVA・C#・Python)があり、またメモリ量にも制限があります。

API Gateway

APIを簡単に作成・運用できるサービス。
Lambdaと連携することで、Lambda関数に対してエンドポイントを張る事が可能。

SES

AWSが提供する、Simple Email Serviceのこと。
Eメールの送受信プラットフォームです。

構成図には書いていないけど使った機能

Certificate Manager
ドメイン(サブドメインや、ワイルドカードも可能)に対してSSL証明書を無料で発行できる。

処理の流れと実装方法

以下に大まかに流れを書いていきます。細かい部分の情報は各自調べるのが確実です。

① コンポーネントのセットアップ

S3、Cloud Front共にセットアップしていきましょう。
2つのS3はそれぞれ以下の役割を請け負ってもらいます。
・静的Webサイトホスティング
・リクエストのリダイレクト

バケット名とドメイン名を一致させる必要があります。

また、S3にサイトのファイルをアップロードしましょう。
www.example.com の方はどっちみちリダイレクトされてしまうので、 example.com の方のみにアップロードします。
フォーム部分に後でajaxを仕込みますが、この時点では大丈夫です。

以下のページが参考になります。

Amazon S3 + CloudFront で始める静的サイトホスティング

静的Webサイトホスティング時には、S3のエンドポイント(S3を指すURLのこと)が通常と変わるので注意です。

Amazon ウェブサイトと REST API エンドポイントの主な違い

      

② ドメインの購入とルーティングの設定

Route53にてドメインの購入とルーティングの設定を行っていきましょう。

③ Cloud Frontを用いた通信のssl化

Certificate Managerを用いてSSL証明書を発行します。
それをCloud Frontに設定することで、通信のssl化が可能となります。
httpで来たアクセスをhttpsにリダイレクトするための設定はこちら。

ビューワーと CloudFront との通信で HTTPS を必須にする


これ以降の④〜⑦に関しては、このページにわかりやすくまとまっていました。

AWS Lambdaで静的サイトにメール送信フォームを作る簡単な方法

④ メール送信用のLambda関数の作成

筆者はPythonで書きましたが、巷にはNode.jsで書いたコードが多いように思えます。
Pythonだとboto3というライブラリを使います。send_email関数しか使いませんが(笑)

Boto 3 Docs 1.4.8 documentation
[boto3]SESを使ってメールを送信する

コード量はそこまで多くはなりません。
フォームから送られてきた情報を、SESのライブラリ関数に渡す、というイメージ。
フォームに記入されたメルアドには確認とお礼のメールを、コード上に予め登録した管理者メールには通知のメールを送るようにしました。

SES利用時には、初期設定が「サンドボックスモード」である ことに注意しましょう。
「サンドボックスモード」では、セキュリティの観点から認証済みのメルアドにのみメールを送れます。
お問い合わせした人のメルアドを事前に認証することは不可能ですので、もしメールを送信したい場合には「サンドボックスモード」の解除申請を行いましょう。

Amazon SES サンドボックス外への移動

⑤ Lambda関数をAPI Gatewayで登録する

これによって、エンドポイントを作成し、コーポレートサイトのフォームに埋め込んだajaxからapiを介してLambda関数を叩けるようにします。
普通にajaxからAPIを叩こうとすると、Cross Originに関してエラーが出てしまいます。
これを防ぐためにはこれを参考に、CROSSの有効化を行いましょう。

API Gateway リソースの CORS を有効にする

⑥ フォームにajaxを埋め込む

⑤で作成したエンドポイントに対してajaxでフォームデータを送りつけます。

これにて完了です!素敵な静的ページライフをお送りください。

続きを読む

【インターン】実際に依頼した仕事と今後の課題を列挙するよ(2017年12月版)

はじめに

この記事は、【インターン】実際に依頼した仕事と感想を列挙するよ(だいたい技術要素ベース)の続編です。
2ヶ月の間の特筆すべき差分と、今後の課題などを記載します。

想定読者など

  • 学生:インターンを検討している人/参加している人

    • 技術的な意味で、インフルのエンジニアインターンでどのような事をするのか、なんとなくわかります。
    • 他の人がどんな事をしていたのか、網羅的になんとなくわかります。
  • その他企業の人:インターン実施を検討している人
    • うまくインターンの学生を集めれば、このような作業を依頼できるかも?という実例を知る事ができます。

株式会社インフルについて

2017年1月創業、3月より本格始動して、自社Webサービスを複数展開している会社です。各サービスの詳細は割愛しますが、自社サービスのアジャイル的な開発・運営を軸として、基幹システムやその他業務システムの受託開発もやっています。

依頼した仕事など

前回までで、以下のような技術を用いた作業を依頼していました。(各技術の概要などは前回記事を参照ください。)

  • 実装関連

    • 開発環境構築

      • 多段ssh/portforward(ssh tunnel)
      • git/bitbucket(ソース管理)
      • PyCharm/WebStorm etc.(IDE)
      • SequelPro(MySQL管理ツール)
      • alembic(DBバージョン管理)
      • node
    • python
      • flask(軽量WEBフレームワーク)
      • SQLalchemy(ORM)
      • ※redis(redisはインメモリDB)
      • WTForm(フォーム、バリデーション)
      • PyBabel(i18n)
      • ※GrabzIt(画像出力API)
      • ※opencv(画像処理)
      • xlrd(エクセル加工)
      • apscheduler(スケジューラ)
      • pytest(単体テスト)
      • pandas(データフレーム処理)
      • Apriori(aprioriアルゴリズム:アソシエーションルール)
    • TypeScript/JavaScript
      • angular(定番)
      • react
      • react-redux
      • d3(データビジュアライズ)
      • highcharts(チャート)
      • introjs(チュートリアル的な奴)
      • snowshoe(電子スタンプ、通信先必須)
      • wScratchPad(スクラッチ削る奴)
      • japan-map(日本地図)
      • jquery-gantt(ガントチャート)
      • jcrop(画像切り抜き)
      • add to homescreen(ホーム画面に追加を促すバルーン)
      • add to calendar(カレンダーに追加する機能)
      • bootstrap-tagsinput(タグ入力的な奴)
      • bootstrap-colorpicker(カラーピッカー、色を選ぶ奴)
      • image-picker(画像とか選ぶ箱)
      • slick(スライダー)
      • exif.js(EXIF取得)
    • テストほか
      • locust(負荷試験)
      • owasp zap(脆弱性診断)
      • squash-tm(テスト管理)
      • circle ci(CI環境)

以下、前回との特筆すべき差分です。

本番環境構築

本番環境を顧客別に用意する場面が出たので、管理監督しながら、全くゼロの状態からの構築を実際にやって貰いました。具体的な内容は以下のようなことです:

NAT用インスタンスの作成、設定

EC2インスタンスの作成

RDSの開始、設定

ElastiCache(Redis)の設定

EC2のサーバーにansible使って関連ツール、製品のデプロイ

S3の開始、設定

SESの開始
、設定

zabbixの設定

bugsnagの設定

これらは全て手順までQiita:Teamにまとめてもらったので、誰でも本番環境(相当の環境)を構築できるようになりました。

(モバイル)ネイティブアプリ作成

cordova + vue

android

製品の利用

FileMakerを用いた業務システム開発

クライアントの自動テストの仕組み構築

ざっくりとした指示だけで、以下の様なものを組み合わせてTypeScriptのUT環境を作ってもらいました。

karma

jasmine

istanbul

他社API連携

決済インターフェイス構築

進捗のあった課題

情報共有

当初はポータルサイトの充実+slackの充実を考えていたのですが、インターン生の提案によりQiita:Teamを採用しました。
いま記事数で125件かな?半分ぐらい私が書いていますが、10000件を超えると消えてしまう無料slackのダイレクトメッセージを探すよりは生産的になったかなあと思います。
slackを有料にするのと、Qiita:Teamを使うのとでコスト的な比較は難しいですが…
ただ、インターン生が圧倒的多数を占めるような会社においては、個人の利用時間と金額のバランスが通常の会社よりも不利なので、ちょっと優しくしてくれる仕組みがあってもいいのになーと思っています。

課題整理・進捗管理

一部では課題管理表を使い始めました。全員で使っている訳ではありません。
現状、通常運用に乗っているサービスはJooto、乗ってないサービスの開発中の課題は課題管理表、という感じです。

顧客からの様々なヒアリング方法

インターン生とは全員と漏れなく機密保持契約を結んでいるので、業務上必要な範囲でQiita:Teamに議事録に相当する資料や、見積記録等を記載するようにしています。

「仕事」の仕方、自分自身のコスト意識

可能な範囲でちょいちょい仕事の仕方についての言及を含めるようにしました。
あとは、少し緩めの設計資料(例えばエンドポイントの一覧表、APIとDBの項目のマッピング一覧表、などのようなもの)を、WBSとしても使えるよう明示的に作成指示するようにしました。

勉強会の開催

各人が主体的に成果を発表するという意味での勉強会は開催していないのでまだ足りずですが、とりあえず設計講習会を開催してみました。記録は以下:

https://youtu.be/_knn0zoYbho
https://youtu.be/RmoMgraSTtk

進捗のあまりない課題・新しい課題

インターン生内のソースレビュー構造(?)

最終的な確認は逃せないとしても、その手前ぐらいまでのレビューぐらいまでは任せて、自律的な集団にしたい。(組織構造を入れる、のに近いのかな)

結合以上のテストの自動テスト

全く手付かず。テストシナリオとかも手付かず…

詳細設計の書き方

ほぼ手付かず。

単体テストケースの書き方(境界値とか、C0とか、0件・1件・複数件とか、の概念も含む)

ほぼ手付かず。網羅的に微妙なバグを潰す作業よりも、まだまだ根本的に新しい機能の実装を優先することが多い状況。

面談

ちゃんとフィードバックの面談をしないといけないのですが、忙しいという理由をつけてちゃんと実施出来ていないので、きちんとやらないといけません。。。うーん。

その他、感想など

飲み会でオールする人はだいぶ少ない

時代の流れなのかな?まだ警戒されているのかしら、、、
まあ、みんな結構忙しいので、あんまりオールとかできないのかなーという感じもしますが。

医学部生でもインターンを探している

複数名、医学部生の方が作業をしていますが、偉いですね。

4〜5月も9月も応募数はほとんど変わらない

1日1名以上のペースで応募がありました。弊社は渋谷から南麻布(白金高輪)に移転したのですが、それぐらいの移動だと場所はほとんど関係ないように感じました。

おしまい

有給インターンがもっと増えますように!

続きを読む

Amazon SESで受信したメールを転送したい

前置き

SESで受信する特定のアドレス宛のメールを外部の別アドレスへ転送したい。SESの設定でこのへんをポチポチっとやれば…と思ったが、できない。できそうでできない。
そう、SESの標準機能ではメールの転送はできない。

対応方針

思い当たる案は2つ。
1. 受信メッセージをS3へ出力し、それをLambdaで拾って別アドレスへ送信する案
2. Amazon WorkMailを使う案
Lambdaを使う案が主流かもしれないが、自分の場合は品質とスピードを重視して結果的には案2を採用した。

案1 S3への出力とLambdaを使う

SESの受信ルールで、受信メッセージをS3へ出力し、それをLambdaでどうにかして別アドレスへメール送信するのが定石のようだ。

こういった情報を参考にプログラムを作成することになるのだが、文字コードや添付ファイルの有無、メッセージを編集してから転送したい、などいろいろ考慮していくとMIMEの深遠なる世界に迷い込んでなかなか大変なことになる。

加えて、SESのS3アクションで「Encrypt Message」オプションを有効化するとS3に格納するメッセージデータが暗号化されるが、それをLambda(Python)側で複合する方法がわからずハマった。というか今も解決できていない。(KMSも絡んで話が長くなるのでこれについてはあらためて別の記事にしたい。)
公式ドキュメント

スクリプト

lambda_function.py
# -*- coding: utf-8 -*-
import boto3
import json
import re
import os

#転送先アドレス(カンマ区切りで複数指定)
FORWARD_TO = os.environ['forward_to'].split(",")

#メール保存先バケット名
S3_BUCKET = "s3-bucket-name"

#転送メールの送信元ドメイン名
DOMAIN_NAME = "hogehoge.jp"

s3  = boto3.client('s3')
ses = boto3.client('ses', region_name="us-east-1")

def lambda_handler(event, context):
    #本来の送信者
    MAIL_SOURCE = event['Records'][0]['ses']['mail']['source']

    #転送メールの送信者
    MAIL_FROM = MAIL_SOURCE.replace('@','=') + "@" + DOMAIN_NAME

    #メール保存先のフォルダ名
    S3_OBJECT_PREFIX = event['Records'][0]['ses']['receipt']['recipients'][0].split("@")[0] + "/"

    #S3上のメールファイル
    s3_key = S3_OBJECT_PREFIX + event['Records'][0]['ses']['mail']['messageId']

    #メールファイル取得
    try:
        response = s3.get_object(
            Bucket = S3_BUCKET,
            Key    = s3_key
        )
    except Exception as e:
        raise e

    #メールヘッダの書き換え
    try:
        replaced_message = response['Body'].read().decode('utf-8')
        replaced_message = re.sub("\nTo: .+?\n", "\nTo: %s\n" % ", ".join(FORWARD_TO), replaced_message,1)
        replaced_message = re.sub("\nFrom: .+?\n", "\nFrom: %s\n" % MAIL_FROM, replaced_message,1)
        replaced_message = re.sub("^Return-Path: .+?\n", "Return-Path: %s\n" % MAIL_FROM, replaced_message,1)
    except Exception as e:
        raise e

    #メール送信
    try:
        response = ses.send_raw_email(
            Source = MAIL_FROM,
            Destinations= FORWARD_TO ,
            RawMessage={
                'Data': replaced_message
            }
        )
    except Exception as e:
        raise e

send_raw_emailを使い、受信したメールのBODYをそのまま送信するのであれば比較的シンプルに実装できそうだ。ただし、一般的なメール転送でよくあるような、メール本文の冒頭に元メールのヘッダ情報を追記するようなことは行っていないため、元メールの送信者がわからないという問題がある。メール本文を編集しようとするとsend_emailを使えば良さそうだが、文字コードやHTMLメール、添付ファイルの考慮など、前述のとおりディープな世界へ足を踏み入れることになり、大変。なのでここでは諦めてシンプルに。

FORWARD_TO = os.environ['forward_to'].split(",")
転送先のメールアドレスはLambdaの環境変数を使って設定する。カンマ区切りの文字列で複数を指定することも可能にしている。

MAIL_FROM = MAIL_SOURCE.replace('@','=') + "@" + domain_name
ここでひと工夫。元メールの差出人アドレスを転送メールの差出人アドレス内に埋め込む。

S3_OBJECT_PREFIX = event['Records'][0]['ses']['receipt']['recipients'][0].split("@")[0] + "/"
SESがS3へ出力する際のPrefixに合わせていれば何でも良いが、ここでは受信アカウントをPrefixとしている。

案2 Amazon WorkMailを使う

月額4USDのコストが許容できるのであればSESの受け口としてWorkMailが使える。WorkMailには転送機能がある。

WorkMailのセットアップ方法は以下がわかりやすい。
AWS WorkMailを使ってみたら想像以上に便利だった

WorkMailでの転送設定は以下(英語の公式ドキュメント)を参考に。
How do I set up an email forwarding rule in Amazon WorkMail?

Lambdaで実現できるはずの機能を月額4USDで逃げるのはエンジニアとして負けた気がしてしまうが・・・スピードと確実性を優先するならアリかと。

続きを読む

クラウドベンダーの比較

はじめに

3大クラウドと呼ばれているAWS、GCP,Azureのリソースを比べてみました。
2017年11月時点の比較となります。

インフラ・サービスレベル

比較項目 AWS GCP Azure 備考
データセンター 各地で借りている すべて自前 各地で借りている(一部自前)
仮想化技術 Xen KVM Hyper-V
リージョン(国内) 1個所 1個所 2個所
リージョン(全国) 15個所 12個所 36個所
SLA 99.95 99.95 99.95 仮想サーバ

サービス面

比較項目 AWS GCP Azure 備考
仮想サーバ Amazon EC2 Google Compute Engine Azure Virtual Machines
仮想サーバ対応OS Amazon Linux,CentOS,RedHat,Windows Server,等 CentOS,RedHat,SLES,Windows Server,等 CentOS,RedHat,Windows Server,等
仮想サーバディスク SSD,HDD SSD,HDD SSD,HDD
仮想サーバスナップショット
仮想サーバオートスケール
コンテナ Amazon ECS Container Engine Container Service
RDB RDS Cloud SQL SQL Database
RDB冗長化
RDBリードレプリカ
RDB DB種別 Aurora,MySQL,MariaDB,Oracle,SQL Server,PostgreSQL MySQL,PostgreSQL SQL Server
NoSQL DynamoDB Cloud Datastore Cosmos DB
ビックデータ Redshift BigQuery App Service
メール Amazon SES
モニタリングツール CloudWatch Stackdriver Azure Monitor
ロードバランサー(L4) CLB Network load balancing Azure Load Barancer
ロードバランサー(L7) ALB HTTP load balancing Application Gateway
CDN Amazon CloudFront Google Cloud CDN Azure CDN
VPN Amazon VPC Google Cloud VPN VPN Gateway
DNS Route53 Google Cloud DNS Azure DNS
専用線 Direct connect Dedicated Interconnect Express Route

サポート面

比較項目 AWS GCP Azure 備考
ランク低 開発者 ($29/月 or 利用料の 3%/月) シルバー ($150/月) Standard($300/月)
ランク中 ビジネス($100/月 or 利用料 の10%/月) ゴールド($400/月) Professional Direct($1,000/月)
ランク高 エンタープライズ($15,000/月 or 利用料の10%) プラチナ(問合せ) Premier(問合せ)

費用面(リージョン日本)

比較項目 AWS GCP Azure 備考
課金単位
ディスカウント リザーブドインスタンス(前払い) 継続利用割引、利用確約の割引(前払い) エンタープライズ契約(前払い)
仮想サーバ(Type) t2.medium(2vCPU,4GB) n1-standard-2(2コア,7.5GB) A2 V2(2コア,4GB)
仮想サーバ(時) $0.0464(5.336円)※1 $0.0950(10.925円)※1 $0.15(17.25円)※1
仮想サーバ(月) $33.408(3841.92円)※1 $48.17(5539.55円)※1,※2 $108(12,420円)※1
インターネットへの転送量 $0.140/GB(10TBまで) $0.12/GB(1TBまで) $0.138/GB(5GB-10TB、5GBまでは無料)
ストレージ利用料 $0.025/GB (最初の50TB/月まで) ※S3 $0.016/GB 月 ※Regional Storage $0.2/GB(最初の50TB/月まで) ※BLOG Storage

※1 $1=115円換算
※2 継続利用割引含む

総括

 AWS、GCP,Azureでのサービス面では同じようなサービスを展開していることが判明。
 インフラ・サービスレベルでは、Azureがリージョン36個とTOPに。
世界的に見て幅を利かせているように思えた。
ただ、GCPはすべて自前のセンターでクラウドサービスを展開していることから、
新しいことをやるにも制約が低いように思えた。
私のイメージ的に一番シェアが高いAWSは、インフラ面ではGCP,Azureに劣っている結果となった。
 費用面では、Azureは割高。AWSが思ったよりも頑張っているように思えた。
 イメージ的にGCPは費用は安いと思っていたが、仮想サーバ比較だと、継続利用割引を使用してもAWSのほうが安い結果となった。
 ただ、費用に関しては、日々値下げ合戦が繰り広げられているので、今後のベンダーさんの努力に期待です。

最後に、費用面での算出に使用した見積もりツールです。
【AWS】http://calculator.s3.amazonaws.com/index.html
【GCP】https://cloud.google.com/products/calculator/?hl=ja
【Azure】https://azure.microsoft.com/ja-jp/pricing/calculator

続きを読む

Node-REDをAWS API Gateway + lambda + S3で動かす方法

はじめに

2017年 Node-RED Advent Calendarの3日目の記事です。

2015年 Node-RED Advent Calendarで@stomiaさんが Node-REDをAWS Lambdaで動かす話 という記事を書かれています。
この方式はS3やSESなどのトリガーで動かせるというメリットがありますが、HTTP inノードの利用を諦める+専用ノードを使ってフローを作る必要がありました。

今回の記事は、HTTP inノードが利用できる状態でNode-REDをlambdaで動かす方法です。
これによってHTTP inノードを使ったフローを修正なしでlamdbaで動かせるようになります。
(デメリットとしてAPI Gateway以外のトリガーでは動かせません。)

また、フロー更新のたびに毎回flow.jsonを含んだNode-REDをlambdaにデプロイする構成では、デプロイ時間がネックで修正サイクルがリズムよく回せません。
これでは開発効率が悪いので、flow.json ファイルはS3に置いてフロー更新はS3のファイルを更新すれば済む構成にします。

構成図

今回の構成は下図のとおりです。この記事では青点線範囲の設定方法を説明します。
node-red-on-lambda-with-api-gw-overview.png

準備するもの

  • AWSアカウント
  • AWS CLI が使える端末(AWSアクセスキー他が設定済みであること)

    $ export AWS_ACCESS_KEY_ID=AKIAXXXXXXXXXXXXXXXX
    $ export AWS_SECRET_ACCESS_KEY=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
    $ export AWS_DEFAULT_REGION=us-west-2
    
  • ブラウザ

設定方法

  • 所要時間参考:約10分
  1. GitHubからaws-serverless-node-red リポジトリをクローンします

    $ git clone https://github.com/sakazuki/aws-serverless-node-red.git
    $ cd aws-serverless-node-red
    
  2. 自分のAWS環境に合わせた設定ファイルを準備します

    $ AWS_ACCOUNT_ID=123456789012
    $ S3_BUCKET=nodered12
    $ AWS_REGION=us-west-2
    $ AWS_FUNCNAME=api12
    $ AWS_STACK_NAME=Node-RED
    $ npm run config -- --account-id="${AWS_ACCOUNT_ID}" 
    --bucket-name="${S3_BUCKET}" 
    --region="${AWS_REGION}" 
    --function-name="${AWS_FUNCNAME}" 
    --stack-name="${AWS_STACK_NAME}"
    

    ※これにより次のファイルが自分のAWS環境用に更新されます。

    package.json
    simple-proxy-api.yaml
    cloudformation.yaml
    settings.js
    
  3. Node-REDと必要パッケージをインストールして、lambdaにデプロイします。

    $ npm run setup
    
  4. PC上でNode-REDを起動してフローを作成します

    $ node node_modules/.bin/node-red -s ./settings.js
    

    http://localhost:1880 にブラウザでアクセスしてNode-REDエディタでフローを作成します。
    HTTP inノードが使えることを確認するためフォームのサンプルフローを作ります。
    node-red-on-lambda-flow.png

    フローデータはこちら

    コピーして、右上のドロップメニューから[読み込み]-[クリップボード]でインポートできます

    
    [{"id":"e164ca79.d4bba8","type":"http in","z":"d540fb70.fb4658","name":"","url":"/hello","method":"get","upload":false,"swaggerDoc":"","x":170,"y":100,"wires":[["f5cc40d7.836fd"]]},{"id":"4818807c.9a996","type":"http response","z":"d540fb70.fb4658","name":"","statusCode":"","headers":{},"x":510,"y":100,"wires":[]},{"id":"f5cc40d7.836fd","type":"template","z":"d540fb70.fb4658","name":"form","field":"payload","fieldType":"msg","format":"handlebars","syntax":"mustache","template":"<form method="POST">n    Input your name<input type="text" name="key1">n    <input type="submit">n</form>","output":"str","x":350,"y":100,"wires":[["4818807c.9a996"]]},{"id":"5c77ba58.b744e4","type":"http in","z":"d540fb70.fb4658","name":"","url":"/hello","method":"post","upload":false,"swaggerDoc":"","x":180,"y":180,"wires":[["4c91fba9.11ed84"]]},{"id":"4c91fba9.11ed84","type":"template","z":"d540fb70.fb4658","name":"view","field":"payload","fieldType":"msg","format":"handlebars","syntax":"mustache","template":"<h1>Hello {{payload.key1}}</h1>","output":"str","x":350,"y":180,"wires":[["4818807c.9a996"]]}]
    

  5. 動作確認(ローカル)
    デプロイしたら、次のURLにアクセスしてローカルで動作確認してください。

    http://localhost:1880/hello
    
  6. 動作確認(API Gateway)
    正常動作が確認できたら、API Gateway経由でも確認します。
    次のコマンドでAPI GatewayのApiUrlを確認します。

    $ aws cloudformation describe-stacks --stack-name ${AWS_STACK_NAME} 
    --output json --query "Stacks[*].Outputs"
    [
    [
        {
            "Description": "Invoke URL for your API. Clicking this link will perform a GET request on the root resource of your API.",
            "OutputKey": "ApiUrl",
            "OutputValue": "https://1xxx2y5zzz.execute-api.us-west-2.amazonaws.com/prod/"
        },
        {
            "Description": "Console URL for the API Gateway API's Stage.",
            "OutputKey": "ApiGatewayApiConsoleUrl",
            "OutputValue": "https://us-west-2.console.aws.amazon.com/apigateway/home?region=us-west-2#/apis/1xxx2y5zzz/stages/prod"
        },
        {
            "Description": "Console URL for the Lambda Function.",
            "OutputKey": "LambdaFunctionConsoleUrl",
            "OutputValue": "https://us-west-2.console.aws.amazon.com/lambda/home?region=us-west-2#/functions/api12"
        }
    ]
    ]
    $
    

    ブラウザで ApiUrlにアクセスして動作確認します。

    https://1xxx2y5zzz.execute-api.us-west-2.amazonaws.com/prod/hello
    

    node-red-on-lambda-with-api-gw (6).png
    動作が確認できました。

  7. 後片付け(オプション)
    この手順で作成されたものを削除する場合には以下のコマンドを実行します。

    $ npm run delete-stack
    

まとめ

  • lambdaでNode-REDのフローを動かしました
  • Node-RED on lambdaでHTTP inノードが使えるようになりました
  • フローファイル(flow.json)をS3から読み込ませました。
    • これでNode-RED本体の再デプロイをすることなく、フローファイルだけを更新できるようになり、開発や修正が簡単になりました。

Node-REDで作ったAPIアプリは、lambdaに簡単に載せられることがわかりました。
皆さんも、試してみてはどうでしょうか。

明日は

@taiponrockさんのNode-RED on IBM Cloud with Watson APIの記事です。

参考

続きを読む

HTTP/2対応のElastic Beanstalk環境を構築する

はじめに

サービスの紹介

2017/10/16 にリリースした Snapmap(スナップマップ) は、
「いつ」「なにを」「どこで」「どうやって」撮影したのかが分かるというコンセプトのサービスです。

そんな Snapmap ですが、画像共有サービスなのでサイト全体は HTTP/2 で表示するようになっています。
その効果1もあり、サイトのパフォーマンスを計測するとこんな感じで結構速いです。

Elastic Beanstalkとは

Snapmap は Elastic Beanstalk を使ってアプリケーションサーバーの環境を構築しています。
Elastic Beanstalk は AWS のサービスの一つで、デプロイ・サーバー監視・スケーリングの全てをまるっとやってくれます。

新規サービスで考慮しておくべきことの多くをショートカットできるのはとても魅力的で、インフラにコストを掛けたくなかった今回の案件にぴったりでした。

HTTP/2にする、その前に

Elastic Beanstalk で構築したアプリケーションサーバーを HTTP/2 に対応させるには、ロードバランサーを Application Load Balancer にする必要があります2
ただ、普通に Web の画面からポチポチ作成すると Classic Load Balancerで環境を構築されてしまいます(2017/12/1 現在)。
さらに、悲しいことに環境構築後にロードバランサーの種類は変更できません

なので、一番初めから EB CLI を使って作成する必要があります。
すでに構築してしまっている場合は諦めて別環境を再作成しましょう。

というわけで、自分の備忘録として今回は一から手順を書いていきたいと思います。

手順

AWS CLI / EB CLIのインストール

EB CLI のインストールがまだであれば以下のコマンドでインストールできます。(AWS CLI も後で必要なのでついでにインストールします)

$ pip install --upgrade pip
$ pip install awscli --user
$ pip install awsebcli --user

AWSの設定

aws configure を利用して、AWSへのアクセス情報を設定します。

$ aws configure
AWS Access Key ID [None]: AKIA*********EXAMPLE # アクセスキーを指定
AWS Secret Access Key [None]: wJa***************************EXAMPLEKEY # シークレットアクセスキーを指定
Default region name [None]: ap-northeast-1
Default output format [None]: json

アクセスキーをまだ発行していなければこちらを参考に。

Elastic Beanstalkの環境作成

準備ができたので Elastic Beanstalk の環境を作っていきます。

まず初期設定を行います。
デプロイ用ディレクトリを作成して eb init を実行し、リージョンとアプリケーションを選択します。

$ mkdir hogehoge
$ cd hogehoge
$ eb init

Select a default region
1) us-east-1 : US East (N. Virginia)
2) us-west-1 : US West (N. California)
3) us-west-2 : US West (Oregon)
4) eu-west-1 : EU (Ireland)
5) eu-central-1 : EU (Frankfurt)
6) ap-south-1 : Asia Pacific (Mumbai)
7) ap-southeast-1 : Asia Pacific (Singapore)
8) ap-southeast-2 : Asia Pacific (Sydney)
9) ap-northeast-1 : Asia Pacific (Tokyo)
10) ap-northeast-2 : Asia Pacific (Seoul)
11) sa-east-1 : South America (Sao Paulo)
12) cn-north-1 : China (Beijing)
13) us-east-2 : US East (Ohio)
14) ca-central-1 : Canada (Central)
15) eu-west-2 : EU (London)
(default is 3): 9 # 東京リージョンを選ぶ

Select an application to use
1) [ Create new Application ]
(default is 1): 1 # 新規アプリを選ぶ

Enter Application Name
(default is "hogehoge"): hogehoge # ディレクトリ名がデフォルトになっているのでアプリ名を入力する
Application shibuya_test has been created.

Select a platform.
1) Node.js
2) PHP
3) Python
4) Ruby
5) Tomcat
6) IIS
7) Docker
8) Multi-container Docker
9) GlassFish
10) Go
11) Java
12) Packer
(default is 1): 4 # プラットフォームを選ぶ

Select a platform version.
1) Ruby 2.4 (Puma)
2) Ruby 2.3 (Puma)
3) Ruby 2.2 (Puma)
4) Ruby 2.1 (Puma)
5) Ruby 2.0 (Puma)
6) Ruby 2.4 (Passenger Standalone)
7) Ruby 2.3 (Passenger Standalone)
8) Ruby 2.2 (Passenger Standalone)
9) Ruby 2.1 (Passenger Standalone)
10) Ruby 2.0 (Passenger Standalone)
11) Ruby 1.9.3
(default is 1): 1 # バージョンを選ぶ
Cannot setup CodeCommit because there is no Source Control setup, continuing with initialization
Do you want to set up SSH for your instances?
(Y/n): Y # 対象サーバーにSSHアクセスしたいならYes

Select a keypair.
1) snapmap_bastion
13) [ Create new KeyPair ]
(default is 1): 1 # キーペアを選ぶ

次に環境の作成ですが、ここで注意したいのが、1 つの VPC とアベイラビリティーゾーンが異なる 2 つのサブネットが必要という点です。
可用性確保のためにそういう仕様になっているっぽいです。

つまり先に VPC とサブネットは作成しておく必要があります。
作成ができたら eb create を実行し、環境を作成します。

eb create xxxxxxxx 
    --elb-type application 
    --vpc.id vpc-xxxxxxxx  # 作成したVPC
    --vpc.elbsubnets subnet-xxxxxxxx,subnet-xxxxxxxx  # 作成したサブネット
    --vpc.ec2subnets subnet-xxxxxxxx,subnet-xxxxxxxx  # 作成したサブネット
    --vpc.elbpublic 
    --vpc.publicip

これでサンプルアプリのサイトが構築されます。こんな感じ。

うまく起動したら、環境作成はいったん完了です。

ebextensionsを設置

次にソースコードを HTTP/2 対応させます。

こちらを参考に、ソースコードのプロジェクト直下にHTTPをHTTPSにリダイレクトさせるための .ebextensions ファイルを作ります。

.ebextensions/01_aws.config
option_settings:
  aws:elbv2:listener:443:
    DefaultProcess: default
    ListenerEnabled: true
    Protocol: HTTPS
    SSLCertificateArns: rn:aws:acm:ap-northeast-1:*************************** # 先ほど発行した証明書のARN
  aws:elbv2:listener:80:
    DefaultProcess: http
    ListenerEnabled: true
    Protocol: HTTP
  aws:elasticbeanstalk:environment:process:default:
    Port: 80
    Protocol: HTTP
    StickinessEnabled: true
    StickinessLBCookieDuration: 43200
    HealthCheckPath: /
    HealthCheckTimeout: 30
    HealthCheckInterval: 60
    MatcherHTTPCode: 200
  aws:elasticbeanstalk:environment:process:http:
    Port: 81
    Protocol: HTTP
    HealthCheckPath: /
    HealthCheckTimeout: 30
    HealthCheckInterval: 60
    MatcherHTTPCode: 301
.ebextensions/02_nginx.config
files:
  /etc/nginx/conf.d/redirect.conf:
    mode: "000644"
    owner: root
    group: root
    content: |
      server {
        listen 81;
        rewrite ^ https://$host$request_uri permanent;
      }

Elastic Beanstalk の関連ファイルを無視するよう .gitignore に以下を追加します。

.gitignore
# Elastic Beanstalk Files
.elasticbeanstalk/*
!.elasticbeanstalk/*.cfg.yml
!.elasticbeanstalk/*.global.yml

ソースコードの変更は以上です。

ソースコードの取得

作成したデプロイ用ディレクトリにソースコードを配置します。

$ cd hogehoge # デプロイ用ディレクトリに移動する
$ git init
$ git remote add origin git@github.com:CoachUnited/hogehoge.git
$ rm .gitignore # 自動で作成されてしまうので消す
$ git pull origin master

次に環境変数を設定し、再度デプロイします。

$ eb setenv RAILS_ENV=production HOGE=fuga 〜 # 必要な環境変数をつらつらと
$ eb deploy # ソースコードをデプロイ

これでサイトが正しく表示されれば OK です。
次は SSL 対応をしていきます。

証明書の取得

こちらを参考に AWS Certificate Manager を利用して、サイトドメインで利用する証明書を取得します。

ちなみに、テスト環境もSSL化したい場合はワイルドカード証明書(*.snapmap.jp)を作成すればOKですが、ワイルドカード証明書はルートドメイン(snapmap.jp)には使えないので注意してください。

(なんと、11月の時点でSESでメールを受け取る必要がなくなったそうです :tada:

Route53を設定

あとは Route53 でサイトドメインの Hosted Zone から A レコードを作成して、ElasitcBeanstalk で作成された環境のドメインを割り当ててください。

これですべて完了です。
ブラウザでアクセスして HTTP/2 になっていれば成功です。お疲れ様でした。

まとめ

手順自体はそこそこ長いですが、実際に作業してみるととても簡単に、そして一度作成してしまえば後は AWS におまかせできます。
スモールスタートのプロジェクトには ElasticBeanstalk 超超オススメです!


  1. Vue.js や materializecss の利用も速度向上に大きく寄与しています。 

  2. 画像は CloudFront で配信されているため、Supported HTTP Versions を「HTTP/2, HTTP/1.1, HTTP/1.0」にするだけで HTTP/2 化できます。 

続きを読む