AWS CloudFrontとLambda勉強まとめ

CloudFront

CDN
– Contents Delivery Network
– エッジのキャパシティを利用して効率的かつ高速にコンテンツ配信
→ユーザに最も近いサーバに誘導して、配信を高速化
→エッジサーバではコンテンツのキャッシングを行い、オリジンに負荷をかけない

・最適なエッジへの誘導方法
①ドメイン名問い合わせ(クライアント→DNS)
②IPアドレス問い合わせ(DNS→CloudFrontDNS)
③最適なEdgeアドレス応答(CloudFrontDNS→DNS)
④最適なEdgeへアクセス(クライアントからEdge)
⑤キャッシュがある場合:コンテンツ配信
キャッシュがない場合:オリジンサーバから取得

・CloudFront特徴
– 84拠点のエッジサーバ
– 予測不可能なスパイクアクセスへの対応
– ビルトインのセキュリティ機能(WAF連携、DDoS対策)
– 充実したレポート

・動的コンテンツ:ELBでEC2に負荷分散。HTML
静的コンテンツ:S3などで保存

・84エッジロケーション→11リージョナルキャッシュ→オリジン
→オリジンに対するコンテンツ取得を削減

CloudFront Distribution
– ドメインごとに割り当てられるCloudFrontの設定
– 40Gbpsもしくは100,000RPSを超える場合上限申請必要
– HTTP/2対応
– IPv6対応
– CNAMEエイリアスを利用して独自ドメイン名の指定可能
→Route53と合わせたZone Apex(wwwがないもの)も利用可能

Gzip圧縮機能
エッジでコンテンツをGzip圧縮することでより高速にコンテンツ配信
※S3はGzip圧縮をサポートしていないので有効

キャッシュコントロール
– キャッシュヒット率の向上がCDNのポイント
→URLおよび有効化したパラメータ値の完全一致でキャッシュが再利用

キャッシュの無効化
コンテンツごとの無効化パス指定

ダイナミックコンテンツ機能
オリジンサーバに対して下記情報をフォワードすることで、動的なページの配信にも対応
– ヘッダー(必要最小限)
– Cookie(Cookie名と値をセットでCloudFrontがキャッシュ)
– クエリ文字列パラメータの値

ダイナミックキャッシング
リクエストパターンをもとにオリジンへのアクセスルールを個別指定可能

カスタムエラーページ
4xx系:クライアントエラー。オリジン側で対処
5xx系:サーバエラー。CloudFrontで対処
参考URL:https://goo.gl/NcUQiY

読み取りタイムアウト
CloudFrontがオリジンからの応答を待つ時間を指定
デフォルトは30秒

キープアライブタイムアウト
接続を閉じる前に、CloudFrontがオリジンとの接続を維持する最大時間
デフォルトは5秒

・セキュリティ
– HTTPS対応
– SSL証明書
→専用IPアドレスSSL証明書には申請必要
ビューワーSSLセキュリティポリシー
→クライアントとCloudFront間のSSL/TLSプロトコルとCipherの組み合わせを指定可能
– オリジン暗号化通信
– オリジンカスタムヘッダー
GEOリストリクション
→地域情報でアクセス判定。制御されたアクセスには403を応答
署名付きURL
→プライベートコンテンツ配信。
→署名付きURLを生成する認証サイトにクライアントから認証リクエスト
→認証サイトからEdgeにアクセス※署名付き出ない場合は、403を返す
-オリジンサーバーの保護
→Origin Access Identitiy(OAI)を利用
S3のバケットへのアクセスをCloudFrontからのみに制限
– AWS WAF連携
AWS ShieldによるDDoS攻撃対策
ブロック時は403応答
– AWS ShieldによるDDoS攻撃対策
デフォルトで有効

・CloudFrontレポート・アクセスログ機能
任意のS3バケットに出力可能

・CloudWatchアラームの活用
リアルタイム障害・異常検知

・S3オリジン自動キャッシュの無効化(Invalidation)
S3にアップロード→Lambdaファンクション呼び出し→CloudFront Invalidation APIの呼び出し→CloudFront上でキャッシュの無効化

Lambda

高度にパーソナライズされたウェブサイト
ビューワーリクエストに応じたレスポンス生成
URLの書き換え
エッジでのアクセスコントロール
リモートネットワークの呼び出し

参考URL:https://www.slideshare.net/AmazonWebServicesJapan/aws-blackbelt-online-seminar-2017-amazon-cloudfront-aws-lambdaedge

続きを読む

AWS RDS勉強まとめ

・RDSの制限事項
バージョンが限定
キャパシティに上限
OSログインやファイルシステムへのアクセス不可
など

上記が許容できない場合はOn EC2かオンプレミスで構築

Multi-AZ
同期レプリケーションと自動フェイルオーバー
インスタンスやハードウェア障害時など

リードレプリカ
デフォルトで5台増設可能
マルチAZやクロスリージョン対応も可能
マスタと異なるタイプに設定可能
読み取り専用などに設定し、スループット向上

・スケールアップ、スケールダウン可能

・ストレージタイプ
汎用SSD
プロビジョンドIOPS
マグネティック

・バックアップ
自動スナップショット+トランザクションログをS3に保存
1日1回設定した時間に自動スナップショット取得、保存期間は0日~35日、手動スナップショットも可能

・リストア
スナップショットをもとにDBインスタンス作成
指定した時刻の状態にすることも可能(Point-in-Time)

・スナップショットはDBインスタンスのサイズと同サイズまでコスト無料
・自動スナップショットはDBインスタンス削除と同時に削除
※手動スナップショットは削除されないので、削除前に最終スナップショットをとること推奨
・スナップショット実行時にI/Oが停止するが、マルチAZの場合はスタンバイから取得するためアプリへの影響なし

リネーム
RDSに接続する際のエンドポイントを切り替える機能
旧本番インスタンスをリネーム→新本番インスタンス(スナップショットからリストア)をリネーム

・リネームの注意点
DNSはすぐに切り替わるわけでない
CloudWatchのMetricNameは引き継がない
マスターをリードレプリカの関係、タグ、スナップショットは引き継ぐ

・RDSにかかわる制限事項
RDSインスタンス数:40
1マスターあたりのリードレプリカ数:5
手動スナップショット数:100
DBインスタンスの合計ストレージ:100TB
必要に応じて上限緩和申請

・デフォルトではDBインスタンスに対するネットワークアクセスはオフ
→セキュリティグループで制御し、アクセス許可のポートなどを指定

・DBインスタンスとスナップショットの暗号化可能

オンデマンドDBインスタンスVSリザーブドインスタンス
リザーブドインスタンス:予約金を支払うことで価格割引

参考URL:https://www.slideshare.net/AmazonWebServicesJapan/20170510awsblackbeltrds

続きを読む

AWS Auto Scaling勉強まとめ

・需要に応じて自動的にサーバーが増減し、コストカット

Auto Scaling Group
・設定した最小値~最大値に起動インスタンスを収める
・起動台数をAZ間でバランシング
・AZ障害時は他のAZでインスタンス起動

Launch Configuration
・AMIやインスタンスタイプ、IAMなどを設定して起動する

Scaling Plan
・どのようにインスタンスを起動するか
①Auto Scaling Planの維持
最小台数を維持する。
Auto Healing:インスタンスに障害発生時に自動的にサービスから切り離し、健全なインスタンスをサービスイン

②手動管理
インスタンスを手動で変更

③スケジュールベース
CLI/SDKで定義
スケーリング開始は最大2分遅れる場合があるので注意

④動的スケーリング
監視:CloudWatchに応じたインスタンスの増減

上記の複数のプランを組み合わせることも可能

ヘルスチェック
①EC2ヘルスチェック:インスタンスのステータスがrunning以外を以上と判断
②ELBヘルスチェック
・ヘルスチェックの猶予期間がある。インスタンス起動からヘルスチェック開始までの時間。アプリケーションデプロイを考慮
・異常と判断されたインスタンスは自動的に終了

クールダウン
スケーリングアクション実行後指定した時間は次にスケーリングアクションを実行しない仕組み
→インスタンス初期化中の無駄なスケーリングを回避するため
※シンプルスケーリングポリシーにのみ対応

ターミネーションポリシー
①OldestInstance/NewestInstance:起動時刻
②OldestLaunchConfiguration:最も古いLaunch Configuration
③ClosestToNextInstanceHour:課金のタイミングが近い
④Default:②③の順に適用。複数インスタンスが残ればランダム

インスタンス保護
任意のインスタンスを削除されないよう保護できる

・インスタンスのデタッチ、アタッチ、スタンバイ

ライフサイクルフック
Auto Scalingの起動/終了時に一定時間(デフォルトは1時間、最大48時間)待機させ、カスタムアクションを実行できる

・スケールアウト時の初期化処理
①設定済みのAMIを用いる
②user-dataで初期化スクリプトを実行(Bootstrap処理)
③ライフサイクルフックで初期化

・サーバーをステートレスにする
ステートレス:サーバーにセッション情報などがない。スケールアウトに向いている
ステートフル:サーバーにセッション情報あり。常にサーバー間で同期が必要なので、スケールアウトに向いていない

・突発的なスパイクには向いていない
→インスタンス作成~アプリ起動の時間がかかるため。
対応策としては、
①CloudFrontなど大きなキャパシティを持ったAWSサービスに処理をオフロードする
②スパイクを裁くのを諦め、スロットリング機能(処理性能の上限)を設ける
③一定以上の負荷を超えたら静的ページに切り替える

・ユースケース
①ELB配下のWebサーバーをAuto Scaling
→EC2は複数AZに分散し、高可用性
ELBのリクエスト数、EC2の平均CPU使用率などがトリガー

②SQSのジョブを処理するWorkerをAuto Scaling
キューのメッセージ数などがトリガー

③Blue/Green
Blue/Green
デプロイ時に、既存のインスタンスとは違うインスタンスを作成し、一気に/徐々に作成したインスタンスを使用するようにする。
移行方法は下記
・DNSのWeighted round robinを使用して、徐々にトラフィックを移行
→DNSのTTLを考慮する必要あり。
・ELBを利用して、移行する
→Elastic Container Service(ECS。Dockerコンテナを格納する場所)を利用して、新しいインスタンスを作成することも可能

In place
デプロイ時に既存のインスタンスを操作することで対応する

参考URL:http://aws.typepad.com/sajp/2015/12/what-is-blue-green-deployment.html

Elastic MapReduce(EMR)

<Hadoop(分散処理をしてくれるソフトウェア)を動かせる環境を提供してくれるサービス
参考URL:http://mgi.hatenablog.com/entry/2014/05/04/085148

参考URL:https://www.slideshare.net/AmazonWebServicesJapan/aws-black-belt-online-seminar-2017-auto-scaling

続きを読む

AWS S3を使ってUnity WebGLの開発で起こったこと。

まえふり

UnityでWebGL向けに開発し、ネットに公開するには何らかの方法でサーバーが必要になります。
本番をどのように対応するかはさておき、簡単かつ無料でWebGLを公開したいのであればAWSの1年無料枠でS3を使って動作確認しました。

そのときの内容とトラブったことのまとめになります。
個人的に、Unity使ってWebGL向けの開発をしている人で、WebGLのデータを置くサーバーを検討している人やどうするのか分からない人などにこの記事を参考にしていただけると幸いです。

環境

  • Unity 2017.2.0f3

    • WebGL
  • AWS(無料枠)
    • EC2, S3

Unity WebGLでの開発について

クロスドメインとCORS

Unity内でサードパーティなどの外部連携の際、APIをWWWなどで処理させると思います。

WWWの処理は、Unityがビルドするプラットフォームに合わせて対応しているため、iOS/Androidだったらネイティブの通信処理に合わせた対応が行われており、WebGLはJavascriptのXMLHttpRequestで対応している模様。
WebGLでサードパーティなどの外部連携を行うと必ず、クロスドメイン問題が発生します。

今回のクロスドメイン問題の対応は、開発しているゲーム専用のAPIも開発していたので、そこを経由して外部連携することにしました。

 
   

 

検証: S3でCORSの設定について

S3には、外部からのアクセスを考慮するためCORSの設定があります。これは外部向けに設定するケースっぽいから、今回はその逆なので関係ナッシング。

PHPで説明するところの

header('Content-type: application/json');
header("Access-Control-Allow-Origin: *");

を対応しないと解決しないので、実は記事書いている時に気づいたものの、、ふぅ笑

だいたいの人がサーバーを用意することが多いよねー。

関連記事:
* WebGL WWW security (Cross-Origin Resource Sharing) help please
* Unity 5 の WebGL で外部からテクスチャを与える方法について調べてみた

HTTPS(SSL)

今回、プライベートでの開発でなるべくお金をかけて開発したくなかったため、AWSの1年間無料枠を前提に開発を進めていました。EC2にはパブリックDNS、S3にはリンクが用意されるので、ドメインを用意することなく動作確認までできちゃいます。

スクリーンショット 2018-01-21 13.45.08.png

スクリーンショット 2018-01-21 13.49.37.png

ただし、S3はhttpsでEC2はhttpなので、S3はAWSが提供しているSDKを使って、データのダウンロードをすることがありますが、直リンクで扱うことも全然あるので、セキュリティ関連で問題になったりならなかったり。

今回、EC2のパブリックDNSによって、「Mixed Content: The page at …」というエラーに遭遇しました。

Mixed Content: The page at …

実際には↓こんなエラーです。

スクリーンショット 2018-01-21 14.22.05.png

Wordpressでよく遭遇する問題としてよく見かけますが、今回の場合だと、サードパーティで扱われるAPI群が全てHttpsで用意されていたため、Httpで統一する方法が取れず、EC2のパブリックDNSでは限界がきた感じ。

対応方法

Route53でドメインを購入し、ACMでSSL証明書を発行してRoute53とロードバランサーと連携する方法になるかと思います。

まとめ

ここまでで大きなトピック2つをご紹介しました。
全て把握すると開発中でなくても情報さえ把握しておけば、今回のようなことは設計段階で解決する内容だと思います。
知っておけば設計段階で問題解決することは、どんな分野でも一緒ってことですねー。

特に経験者には敵いませんねぇ、、ホント笑
 

続きを読む

Amazon VPC勉強メモ

・ネットマスクは/28(14IP)-/16の範囲で利用可能
サブネットで利用できないIP
1. ネットワークアドレス(.0)
2. VPCルータ(.1)
3. Amazonが提供するDNS(.2)
4. AWSで予約されている(.3)
5. ブロードキャストアドレス(.255)

・VPC作成後はVPCアドレスブロックは変更できない

・同一リージョン内のAZは高速専用線でつながっている。リージョン間はインターネット経由

ネットワークACL(アクセスリスト)でネットワークレベルでのセキュリティソフトを設定

ENI(Elasticネットワークインターフェース)
EC2で利用するネットワークの仮想インターフェース
EC2ごとにENIを複数持つことが可能
下記の情報をENIに紐づけて維持可能
1. プライベートIP(固定の設定可能)
2. Elastic IP
3. MACアドレス
4. セキュリティグループ

Floating IP
サーバに障害が起こった際に、ENIを維持して対応する
※VPCではサブネットを超えてアドレスを付け替えることができない点に注意
参考URL:https://goo.gl/JKphCj

サブネット内のDHCP
サブネット内のENIにIPを自動割り当て
※プライベートIPを固定にした場合はDHCP経由で該当のIPが割り当てられる

・VPCで使えるAmazonが提供するDNS
169.254.169.253
VPCのネットワーク範囲のアドレスに+2をプラスしたIP

プライベートホストゾーン
VPC内のインスタンスのみ参照可能。Route53のプライベートホストゾーンを利用

インターネットゲートウェイ(IGW)
VPC内のリソースにインターネットの接続を提供。VPCにアタッチする
単一障害店や帯域幅のボトルネックはない

メインルートテーブルカスタムルートテーブル
メインルートテーブル:VPCを作成したときに自動的に割り当て
カスタムルートテーブル:任意で作成したルートテーブル。メインに変更することも可能

パブリックサブネットの設定
自動で割り当て:サブネットに自動割り当てを設定
固定で割り当て:Elastic IPをアタッチ

Elastic IP
費用がかかるのは下記の場合
1. 追加でEIPを利用する場合
2. 起動中のEC2インスタンスに割り当てられていないとき
3. アタッチされていないENIに割り当てられている場合
4. 1ヶ月でリマップ(割り当て、取り外し)が100回を超えた場合

NATゲートウェイ
プライベートサブネットのリソースがインターネットに通信するために必要
AZごとに設置するのがベストプラクティス

VPCエンドポイント
プライベートサブネットからS3バケットにアクセス可能
S3アクセスのためにIGWNATインスタンスが不要

バーチャルプライベートゲートウェイ(VGW)
オンプレミスとのVPN接続のためのエンドポイントとなる仮想ルータ。VPC側
単一障害点や帯域幅のボトルネックはなし

カスタマゲートウェイ(CGW)
オンプレミス側。AWSとのVPN接続のため

VPN接続
VGWCGW間でIPsecトンネルが設定

・VPC Peering

2 つの VPC 間でトラフィックをルーティングすることを可能にするネットワーク接続
https://docs.aws.amazon.com/ja_jp/AmazonVPC/latest/UserGuide/vpc-peering.html

ネットワーク接続の最大送信単位 (MTU)に注意。VPC Peeringは1500

異なるAWSアカウントでも可能
但し、異なるリージョン間では使用できない

セキュリティグループ
仮想ファイアウォール
1つのEC2で5つのセキュリティグループが設定可能
デフォルトですべての通信は禁止
VPCぴあリング先のセキュリティグループが設定可能

ネットワークACLVSセキュリティグループ
ネットワークACL:サブネットレベルで効果。ステートレスなので戻りのトラフィックも明示的に許可設定
セキュリティグループ:サーバーレベルで効果。ステートフルなので戻りのトラフィックは気にしなくてよい

・オンプレミスとのハイブリッド構成
Direct Connectを使用する
VPCからオンプレミスへの通信をするためには、各サブネットのルートテーブルの設定が必要
宛先:オンプレミスのIP
ターゲット:VGWのID
VPNとDirect Connectで冗長可能。Direct Connectが優先

・VPC設計
アプリケーション/監査/フェーズ(本番/検証/開発)/部署などによる分割

VPC Flow Logs
ネットワークトラフィックをキャプチャ氏、CloudWatchへPublishする機能
ネットワークインターフェースを送信元/送信先とするトラフィックが対象
CloudWatch Logsの標準料金のみ課金
VPC Flow Logsで取得できない通信
1. Amazon DNSサーバへのトラフィック

・VPCのリミット
リージョン当たりのVPCの数:5
VPC当たりのサブネット:200
AWSアカウント当たり1リージョンのEIP:5
ルートテーブルあたりのルートの数:100
VPCあたりのセキュリティグループの数:500

参考URL:
http://kakakakakku.hatenablog.com/entry/2016/08/07/232305
https://www.slideshare.net/AmazonWebServicesJapan/aws-black-belt-online-seminar-2016-amazon-vpc

続きを読む

「Microservices Meetup vol.6」に行ってきた

2017/1/19のデイリーストックランキングにランクインしました。

【毎日自動更新】Qiitaのデイリーストックランキング!ウィークリーもあるよ_-_Qiita.png


いままでの。
「Microservices Meetup vol.2」行ってきたメモ。
「Microservices Meetup vol.4」に行ってきた

図らずして1回おきに参加してますね。

Connpassのイベントページ

少し間が空いてしまったがまた定期的に開催していきたいです。
登壇したいよーって人は直接リプ投げてください
by @qsona さん

Microservices on AWS by @Keisuke69 さん

Keisuke Nishitani @ AWS

Specialist Solutions Architect

サーバーレスアプリケーション開発ガイド 2月発売

マイクロサービスのポイント

  • 管理運用まで含めて分散型
  • 各コンポーネントが独立している
    • 単独で実行できないのは適切に設計されていない

独立して分散していると負荷の高い機能の単位でスケールさせられる=コスト効率が良い

  • 一つのことをうまくやる

    • 複雑化したら分割する
  • 多言語

    • チーム(機能)にはそれぞれの問題に対して適切なツールを選択する自由がある
    • OS、言語、各種ツールに至るまで最適なアプローチを目指せる
  • 検索:Elasticsearch / Solr

  • ソーシャル:グラフDB

  • ログデータ:Cassandra

  • セッション:Redis

†AWSでは:AWSには100ちょいのサービスがあって、その中で更にチームが分かれている。
各チームに社内標準の開発プロセスは存在しない。

  • ブラックボックス

    • 詳細は外部のコンポーネントに公開されない
  • DevOps
    • マイクロサービスにおける組織原理

†AWSでは:運用のみのチームはない。オンコールも開発チームが請け負う

  • 俊敏性

    • 狭い範囲のコンテキストで活動=サイクルタイムが短い
    • システムもシンプル
    • パラレルな開発とデプロイが可能
  • イノベーション

    • 選択に対する権限と責任を持つのでイノベーションを起こしやすい
    • DevとOpsの対立がないため、効率化やイノベーションが起こしやすい
  • 拡張性

    • 適切に非干渉化されてていることで水平方向に単独にスケールできる
  • 可用性

    • ヘルスチェック、キャッシング、隔壁、サーキットブレーカーと言った仕組みは全体の可用性を向上させる

課題

  • 分散型であることは難しい

    • システム数が増える
    • 協調動作の難しさ
    • コンポーネント間のコミュニケーションメッセージ増によるレイテンシ低下
    • ネットワークの信頼性は無限ではない、帯域も無限ではない
  • 移行が大変
    • モノリシックなシステムの分割は難しい
  • 組織
    • 組織体制の変更が必要になるが、それは大変なこと
  • アーキテクチャの難易度
    • 非同期通信
    • データ整合性
    • やっぱりココが一番の課題
    • サービスディスカバリ
    • 認証
  • 運用の複雑さ

アーキテクチャ

一番シンプルなパターン

CloudFront – ALB – ECS – datastore(ElastiCache, Dynamo, )
|
S3

  • バックエンドをRESTfulなAPIにしたSPA
  • 静的なコンテンツはS3とCloudFront
    • CDN通すことでレイテンシが上がることもある
    • キャッシュとの併用を検討
  • ECSとAutoScalingをALBとともに使うことが多い
    • ALB(L7LB)でアプリレベルの情報をルーティング
    • コンテナインスタンスにリクエストを分散
    • ECSのコンテナを負荷に応じてスケールアウト/インする

コンテナのメリット

  • Portable
  • Flexible
  • Fast
    • 軽量で早い
    • ポータビリティと関連して開発サイクルも早く
  • Efficient

  • 一貫性のある環境

  • バージョン管理出来る

Dockerの特徴

  • Package
  • Ship
  • Run

ECS

  • 複数のコンテナをEC2のクラスタ上で一元管理

    • まだTokyoにきてないけど、FargateでEC2の管理もいらなくなるよ
    • EKS(Kubernetes)も発表されています

データストア

  • インメモリ

    • Memcached, Redis
    • ElastiCache
    • DB負荷の軽減
  • RDBMS
    • 無限のスケーリングには向いていない
    • Amazon RDS
  • NoSQL
    • 水平スケーリングをサポートするものが多い
    • テーブル結合ができないのでロジックの実装が必要になる場合も
    • Amazon DynamoDb, KynamoDB Accelarator(DAX)

APIの実装

  • APIの設計、改善、デプロイ、モニタリング、保守派手間がかかる
  • 異なるバージョンが混在すると大変

Amazon API Gateway

  • 複数バージョンとステージ
  • Cognite User Poolsと連携して認証を追加
  • スロットリング、モニタリング
  • バックエンドとしてLamdbaが使える

サーバーレス

  • サーバーはないに越したことはない
  • スケーリングと高可用性の担保が大変
CloudFront - API Gateway - Lamdba - datastore
   |                            (ElastiCache, Dynamo)
   |
  S3

課題をAWSでどうするか

サービスディスカバリ

  • お互いの死活確認や発見
  • ハードコードするとスケールできない

    • メタデータをどこに置くか
  • ALBを利用したサービスディスカバリ

  • DNS(Route53)のサービスディスカバリ

    • VPC単位の振り分け
  • ECSイベントストリームを使用したサービスディスカバリ

    • CloudWatchイベントで拾ってキック
    • LamdbaでRoute53に登録
    • これが一番多いかも
  • DynamoDBを使用したサービスディスカバリ

    • DNSキャッシュの問題がない
    • 自由度が高い
    • 実装が大変
    • DynamoDBストリームを活用して他のサービスへステータス変更を反映
  • イベントベースのアーキテクチャ

    • イベントで処理する
    • いわゆる結果整合性とも関連
    • Dual Write Problem
    • Event Sourcing
      • 状態の記録ではなく状態の変更「イベント」を記録
      • Amazon Kinesis
      • kinesisにpublishして他サービスはsubscribe
      • S3にログを残す
      • トランザクションログの仕組み

モニタリング

  • CloudWatch

    • ログファイルの一元化
    • CloudWatch LogsかS3に保存可能
    • ECSはCloudWatch Logsに一元化できる

分散トレース

  • AWS X-Ray
  • 複数サービスに分散したリクエスト処理を透過的に追える

LogWatchの先に Kinesis FireHorse – ほにゃほにゃ

スロットリング

  • 大事だよ

リトライ

  • 多くのエラーはリトライでカバーできるものが多い
  • リトライ多発で過負荷になることがある
    • Exponential back offもしくはフィボナッチ数列を利用したリトライ感覚の調整
    • 更に乱数でゆらぎを付けて重ならないように

LT:クラウド型医療系業務システムと Microservices への歩み by @hashedhyphen さん

https://speakerdeck.com/hashedhyphen/kuraudoxing-dian-zi-karutesisutemuto-microservices-hefalsebu-mi

クラウド型電子カルテシステムの話

  • メインロジックをRails
  • 常時接続をNode.js
  • バックエンドをScala
  • 基盤はAWS

ここに至る道のり

ファーストリリース前

  • レコメンドは大量のデータが必要

  • メインロジックで実現させようとすると厳しかった

    • Threadとか試したけど……
    • 別アプリケーションとして分離
    • JVM上でScala + Skinnyでスレッドアプリケーションンを実装
    • Microservicesちっくな構成へ
  • 障害検知時

    • メインロジック内のプロトタイプ版が動く!

会計機能リリース前

  • お金を扱う機能は安定性が欲しい
  • Scala + Cats による実装を別エンドポイントとして実装
  • マイクロサービスっぽい作りになっていたから自由度のある技術選択が出来た

まとめ

  • ちょっとマイクロサービス化したことで自由度が上がった
  • 原理主義的にならなくても恩恵がある
  • エンジニアの伸びしろ!

FrontEndからみるmicroserviceとBackendからみるmicroservice by @taka_ft さん

Takahiro Fujii @ Rakuten Travel

楽天内でも採用アーキテクチャはサービスによって異なる。

サービスとしては

  • コンシューマ向け
  • Extranet
  • In-house
  • other
    • ここまではWEBとモバイルがあって、100以上のAPIを利用する
  • API(内部APIを直接利用)

Phase 1

  • 大きなモノリシックなアプリだった
  • 機能がどんどん増えていく
    • 機能別で複数のモノリシックなアプリに分割
    • その後フロントエンドとバックエンドに分割

Phase 2

  • ドメインモデルを整理
  • なるべくRESTfulで作るようになっていった
  • 大きなAPIから小さなAPIに分離
  • I/Fの決定に時間がかかるようになった
  • API呼び出しが大変になった
  • Microservicesっぽくなってきた 2014年くらい

  • 国内予約、海外予約で多言語化だけではない商習慣に根ざしたドメインの差異による重複ロジックの増殖が起きた

  • Microservicesっぽくなってきたが、どんどん品質が下がっていった

Phase 3

(ちょうど前日にプレスリリース)サイト前面刷新に向けての取り組み

  • FrontendsはJavaScriptに刷新
  • API GatewayにKong

組織

  • フロントエンドチームが2人から始まって半年でReactエンジニアを集めて20人以上に

    • 日本人は2, 3人

UI Component

  • SpringからJavaScriptでSPAに変更
  • zeplinのデザインモックからUI Componentを実装するようになった
  • Storyboardを使ってUI Coponentを管理
  • ドメインを含むUI Componentはドメインと結び付きが強いことが多い=専用のオーケストレーションAPIを用意してUI Componentないで処理を閉じることが出来る
  • レスポンシビリティを明示的に定義

    • どこまでフロントエンドでやるか、どこからAPIからもらうか
  • フロントエンドの「使いやすいレスポンス」の要求

  • バックエンドの「汎用的でシンプルなレスポンス」の希望

    • これらのバランスを取る
  • API Gatewayはフロントエンド(UI)チームの管轄

    • ただし状況によってはバックエンド側に持っていくことも検討するつもり

LT: “マイクロサービスはもう十分”か? by @qsona さん

https://speakerdeck.com/qsona/enough-with-the-microservices

POSTDに投稿していた翻訳記事。

スタートアップ企業のほとんどはマイクロサービスをさいようすべきではない

銀の弾丸はない。

「チーム間の依存性」の解決にマイクロサービスというアプローチは違う。疎結合と分散は別。

組織が大きくなると、複数チームが1つのコードベースを触るようになる。そしてマイクロサービス化したくなる。

しかし、モノリスの分割で十分。

チームとは何か

  • 自律的に動けるべき

    • チームが増えるとコミュニケーションコストや、しがらみ
  • チームの分割は目的にそった分割を行う

  • 悪い分割の例: Dev / Ops

  • 依存度が低いほど自律的に動ける

  • High Output という本

  • 使命型組織/技術型組織

    • Micorservicesは使命型組織
    • 組織間が密ならサービス間も密になる

話戻して

  • スタートアップは組織をキレイに分割することが難しい
  • 分割しても密になってしまう

  • 大きなモノリスになるとやはり分割は難しい

    • ドメインの意識は必要
  • マイクロサービス設計しなくても「マイクロサービス精神」で開発すると効果的なのではないか

FiNCが初期からマイクロサービスでやってた理由

  • 単独の事業にできるような一つ一つのサービスを組み合わせて提供してきたから

あとで読み返して修正します。
資料パスの追加とかも。

続きを読む

【AWS】 SSH を使用した Linux インスタンスへの接続

AWSでEC2インスタンスを作成して、SSHで接続できるようにするまでの手順とその過程でハマったことを書き記します。
間違っている、こうした方がわかりやすいなどありましたらコメントお願いします。

インスタンスに新規ユーザーを追加する

1.インスタンス時に得たキーペアファイルを使って接続する

[user@local ~]$ ssh -i kagi.pem ec2-user@[instance name]

2.rootユーザーにパスワードを設定する

[ec2-user@instance ~]$ sudo su -
[ec2-user@instance ~]$ passwd 

3.ユーザーの追加

[ec2-user@instance ~]$ useradd hoge
[ec2-user@instance ~]$ passwd hoge

4.sudoの許可

[ec2-user@instance ~]$ vi /etc/sudoers

5.EC2のサーバへログイン

// ユーザー名
hoge ALL=(ALL) ALL

6.鍵を生成する

// ~/.ssh/に公開鍵と秘密鍵が生成される
[user@local ~]$ ssh-keygen -t rsa

7.公開鍵をインスタンスへ転送し配置する

// 生成した鍵を、一時的にec2-userのディレクトリへ転送する
[user@local ~]$ scp -i kagi.pem ec2-user@[instance name]:/home/ec2-user

8.EC2のサーバへログイン

[ec2-user@instance ~]$ ls
// あるかチェックする
id_rsa.pub

9.追加したユーザーのホームディレクトリにid_rsa.pubを配置する

[ec2-user@instance ~]$ su hoge

10.ホームディレクトリに.sshというディレクトリを作り、id_rsa.pubをauthorized_keysという名前で移動する

[hoge@instance ec2-user]$ mkdir /home/hoge/.ssh
[hoge@instance ec2-user]$ sudo mv id_rsa.pub /home/hoge/.ssh/authorized_keys

11.転送したファイルとディレクトリのパーミッションを変更する

[hoge@instance ec2-user]$ sudo chmod 600 /home/hoge/.ssh/authorized_keys
[hoge@instance ec2-user]$ sudo chmod 700 /home/hoge/.ssh

12.接続

[user@local ~]$ ssh hoge@[instance name]

13..sshにconfigファイルを書く
ログインのたびに面倒な設定を入力する手間を省く為に入力する

[user@local ~]$ vi ~/.ssh/config
Host hoge
user hoge
HostName [public DNSを記述]
Port 22
IdentityFile id_rsa
// ログインできたら成功
ssh hoge

       __|  __|_  )
       _|  (     /   Amazon Linux AMI
      ___|___|___|

注意点・ハマったこと

まずはec2-userにログインしないといけない
そのあとにLinuxコマンドでユーザーを作成
作成したユーザーにパスワードとrootの権限と付与する

※参考
http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/managing-users.html

ユーザーアカウントを追加するには

adduser コマンドを使用して、newuser アカウントがシステムに追加され、 (/etc/passwd ファイルにエントリが追加される

このコマンドでも、グループが作成され、アカウントのホームディレクトリが作成される

[ec2-user ~]$ sudo adduser newuser

ユーザーを Ubuntu システムに追加する場合は、このコマンドを使用して、–disabled-password オプションを追加し、アカウントにパスワードが追加されないようにする

[ec2-user ~]$ sudo adduser newuser --disabled-password

新しいアカウントに切り替えると、新しく作成したファイルに適切な所有権が与えられる

[ec2-user ~]$ sudo su - newuser
[newuser ~]$

newuser ホームディレクトリに .ssh ディレクトリを作成し、
そのファイルのアクセス許可を 700 (所有者のみ、読み取り、書き込み、削除が可能) に変更する

[newuser ~]$ mkdir .ssh
[newuser ~]$ chmod 700 .ssh

authorized_keys という名前のファイルを .ssh ディレクトリに作成し、そのファイルのアクセス許可を 600 (所有者のみ、読み取りおよび書き込みが可能) に変更する

[newuser ~]$ touch .ssh/authorized_keys
[newuser ~]$ chmod 600 .ssh/authorized_keys

authorized_keys ファイルを開きます。キーペアのパブリックキーをファイルに貼り付ける

//例:
ssh-rsa ----
------------
------------
------------
------------
------------
------------
------------
-----EXAMPLE

ユーザーを削除する

[ec2-user ~]$ sudo userdel -r olduser

続きを読む

AWSのEC2で行うCentOS 7の初期設定

AWSのEC2で行うCentOS 7の最低限の初期設定をまとめてみました。まだすべき設定が残っているとは思いますので、こちらを更新していければと思ってい

開発環境

  • Mac OS X(El Capitan) 10.11.6
  • CentOS 7 (x86_64) – with Updates HVM

事前に用意しておく必要があるもの

  • 接続先EC2のパブリックDNS
  • デフォルトユーザ(CentOS 7の場合デフォルトはcentos)
  • EC2からダウンロードした秘密鍵(デフォルトは****.pem)

参考

AWSのEC2にSSH接続

秘密鍵の配置設定

以下のコマンドを実行してEC2からダウンロードした秘密鍵を【.ssh】ディレクトリに配置し、管理しやすくします。

$ mv /Users/ユーザ名/Downloads/秘密鍵名.pem ~/.ssh/

秘密鍵の権限設定

SSHを機能させるためには秘密鍵が公開されていないことが必要ですので、以下のコマンドを実行てし権限の設定をします。

$ chmod 400 ~/.ssh/秘密鍵名.pem

SSH接続

以下のコマンドを実行してAWSのEC2にSSH接続します。

$ ssh -i ~/.ssh/秘密鍵名.pem ユーザ名@パブリックDNS

ログイン完了

以下が表示がされたらログイン完了です。

[centos@ip-パブリックDNS ~]$

CentOS 7の初期設定

SELINUXの無効化

以下のコマンドを実行してSELINUXを無効化します。【Disabled】になったら無効化完了です。

# ステータス確認
$ getenforce

# 設定変更
$ sudo sed -i -e 's/SELINUX=enforcing/SELINUX=disabled/g' /etc/selinux/config

# 再起動
$ sudo reboot

# SSH再接続
$ ssh -i ~/.ssh/秘密鍵名.pem ユーザ名@パブリックDNS

# 無効化確認
$ getenforce

パッケージの更新

以下のコマンドを実行してCentOS 7のパッケージを更新します。

# パッケージの更新
$ sudo yum update -y

パッケージの自動更新設定

以下のコマンドを実行してyum-cronをインストールし、パッケージの自動更新を設定します。

# インストール
$ sudo yum install yum-cron -y

# 有効化確認
$ systemctl list-unit-files | grep yum-cron

# 有効化
$ sudo systemctl enable yum-cron

# 自動更新設定
$ sudo sed -i "s/^apply_updates.*$/apply_updates = yes/g" /etc/yum/yum-cron.conf

# 起動
$ sudo systemctl start yum-cron.service

# 起動確認
$ systemctl status yum-cron.service

タイムゾーンの変更

以下のコマンドを実行してタイムゾーンを変更します。

# 現在の設定確認
$ timedatectl status

# ローカルタイムを【Asia/Tokyo】に変更
$ sudo timedatectl set-timezone Asia/Tokyo

# 現在の設定確認
$ timedatectl status

ロケールとキーマップの変更

以下のコマンドを実行してロケールとキーマップを日本語対応に変更します。

# 現在の設定確認
$ localectl status

# 選択できるキーマップの確認
$ localectl list-keymaps

# ロケールを日本語とUTF-8に変更
$ sudo localectl set-locale LANG=ja_JP.utf8

# キーマップをjp106に変更
$ sudo localectl set-keymap jp106

# 現在の設定確認
$ localectl status

不要なサービスの停止(例:postfix)

以下のコマンドを実行して不要なサービスの停止をします。

# 有効化サービス一覧確認
$ systemctl list-unit-files --type service | grep enabled

# ステータス確認
$ systemctl status postfix.service

# 停止
$ sudo systemctl stop postfix.service

# 無効化
$ sudo systemctl disable postfix.service

# ステータス確認
$ systemctl status postfix.service

ユーザーアカウント追加

ユーザーアカウント追加

以下のコマンドを実行して新規ユーザーアカウントを追加します。今回は【newuser】として作成します。

# newuserを追加
$ sudo adduser newuser

sudo権限の変更

以下のコマンドを実行してsudoersファイルを安全に編集します。

# sudoersファイルの編集
$ sudo visudo

作成したnewuserグループをsudoコマンドがパスワード無しで実行できるように追記します。

## Same thing without a password
# %wheel        ALL=(ALL)       NOPASSWD: ALL
+ %newuser       ALL=(ALL)       NOPASSWD: ALL

ユーザーアカウント切り替え

以下のコマンドを実行してnewuserへ切り替えます。

# newuserへ切り替え
$ sudo su - newuser

公開鍵認証設定

公開鍵認証用ファイルの作成

以下のコマンドを実行して公開鍵認証用のディレクトリとファイルを作成します。

# newuserのホームディレクトリに.sshディレクトリを作成
$ mkdir .ssh

# ファイルパーミッションを700(所有者のみ、読み取り、書き込み、削除が可能)に変更
$ chmod 700 .ssh

# authorized_keysを作成
$ touch .ssh/authorized_keys

# ファイルパーミッションを600(所有者のみ、読み取りおよび書き込みが可能)に変更
$ chmod 600 .ssh/authorized_keys

キーペアのパブリックキーをコピー

以下のコマンドを実行してパブリックキーをコンピュータから取得します。

# パブリックキーをコンピュータから取得
$ ssh-keygen -y

# キーを持つファイルのパスを指定
Enter file in which the key is (/Users/****/.ssh/id_rsa): /path_to_key_pair/my-key-pair.pem

表示されたインスタンスのパブリックキー(※以下は例)の末尾の【キーペア名】を除いてコピーします。

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQClKsfkNkuSevGj3eYhCe53pcjqP3maAhDFcvBS7O6V
hz2ItxCih+PnDSUaw+WNQn/mZphTk/a/gU8jEzoOWbkM4yxyb/wB96xbiFveSFJuOp/d6RJhJOI0iBXr
lsLnBItntckiJ7FbtxJMXLvvwJryDUilBMTjYtwB+QhYXUMOzce5Pjz5/i8SeJtjnV3iAoG/cQk+0FzZ
qaeJAAHco+CY/5WrUBkrHmFJr6HcXkvJdWPkYQS3xqC0+FmUZofz221CBt5IMucxXPkX4rWi+z7wB3Rb
BQoQzd8v7yeb7OzlPnWOyN0qFU0XA246RA8QFYiCNYwI3f05p6KLxEXAMPLE

取得したキーペアのパブリックキーをペースト

以下のコマンドを実行して、コピーしたキーペアのパブリックキーを【authorized_keys】にペーストします。

#.ssh/authorized_keysを編集
$ vi .ssh/authorized_keys

追加したユーザーアカウントでAWSのEC2にSSH再接続

以下のコマンドを実行してAWSのEC2にSSH再接続します。

$ ssh -i ~/.ssh/秘密鍵名.pem 追加したユーザーアカウント@パブリックDNS

ログイン完了

以下が表示がされたらログイン完了です。

[centos@ip-パブリックDNS ~]$

ブログ記事の転載になります。

続きを読む

AWSのEC2で行うAmazon Linuxの初期設定

AWSのEC2で行うAmazon Linuxの最低限の初期設定をまとめてみました。まだすべき設定が残っているとは思いますので、こちらを更新していければと思っています。

開発環境

  • Mac OS X(El Capitan) 10.11.6
  • Amazon Linux AMI 2017.09.1 (HVM), SSD Volume Type – ami-33c25b55

事前に用意しておく必要があるもの

  • 接続先EC2のパブリックDNS
  • デフォルトユーザ(Amazon Linuxの場合デフォルトはec2-user)
  • EC2からダウンロードした秘密鍵(デフォルトは****.pem)

参考

AWSのEC2にSSH接続

秘密鍵の配置設定

以下のコマンドを実行してEC2からダウンロードした秘密鍵を【.ssh】ディレクトリに配置し、管理しやすくします。

$ mv /Users/ユーザ名/Downloads/秘密鍵名.pem ~/.ssh/

秘密鍵の権限設定

SSHを機能させるためには秘密鍵が公開されていないことが必要ですので、以下のコマンドを実行てし権限の設定をします。

$ chmod 400 ~/.ssh/秘密鍵名.pem

SSH接続

以下のコマンドを実行してAWSのEC2にSSH接続します。

$ ssh -i ~/.ssh/秘密鍵名.pem ユーザ名@パブリックDNS

ログイン完了

以下が表示がされたらログイン完了です。

Last login: Mon Jan 15 17:27:41 2018 from ***.***.***.***

       __|  __|_  )
       _|  (     /   Amazon Linux AMI
      ___|\___|___|

https://aws.amazon.com/amazon-linux-ami/2017.09-release-notes/

Amazon-linuxの初期設定

パッケージの更新

以下のコマンドを実行してAmazon-linuxのパッケージを更新します。

# パッケージの更新
$ sudo yum update -y

パッケージの自動更新設定

以下のコマンドを実行してyum-cronをインストールし、パッケージの自動更新を設定します。

# インストール
$ sudo yum install yum-cron -y

# 有効化確認
$ sudo chkconfig --list yum-cron

# 有効化
$ sudo chkconfig yum-cron on

# 自動更新設定
$ sudo sed -i "s/^apply_updates.*$/apply_updates = yes/g" /etc/yum/yum-cron.conf

# 起動
$ sudo service yum-cron start

# 起動確認
$ sudo service yum-cron status

タイムゾーンの変更

以下のコマンドを実行してインスタンスのローカルタイムとハードウェアクロックを変更します。

# 現在の設定確認
$ date

# ローカルタイムを【Japan】に変更
$ sudo ln -sf /usr/share/zoneinfo/Japan /etc/localtime

# ハードウェアクロックを【Japan】に変更
$ sudo sed -i s/ZONE=\"UTC\"/ZONE=\"Japan\"/g /etc/sysconfig/clock

# システム再起動
$ sudo reboot

# 現在の設定確認
$ date

文字コードを日本語に変更

以下のコマンドを実行して文字コードを日本語対応に変更します。

# 文字コードを日本語に変更
$ sudo sed -i s/LANG=\"en_US.UTF-8\"/LANG=\"ja_JP.UTF-8\"/g /etc/sysconfig/i18n

不要なサービスの停止

以下のコマンドを実行してGUIで不要なサービスの停止することができます。

# 不要サービスの一括設定(GUI)
$ sudo ntsysv

ユーザーアカウント追加

ユーザーアカウント追加

以下のコマンドを実行して新規ユーザーアカウントを追加します。今回は【newuser】として作成します。

# newuserを追加
$ sudo adduser newuser

sudo権限の変更

以下のコマンドを実行してsudoersファイルを安全に編集します。

# sudoersファイルの編集
$ sudo visudo

作成したnewuserグループをsudoコマンドがパスワード無しで実行できるように追記します。

## Same thing without a password
# %wheel        ALL=(ALL)       NOPASSWD: ALL
+ %newuser       ALL=(ALL)       NOPASSWD: ALL

ユーザーアカウント切り替え

以下のコマンドを実行してnewuserへ切り替えます。

# newuserへ切り替え
$ sudo su - newuser

公開鍵認証設定

公開鍵認証用ファイルの作成

以下のコマンドを実行して公開鍵認証用のディレクトリとファイルを作成します。

# newuserのホームディレクトリに.sshディレクトリを作成
$ mkdir .ssh

# ファイルパーミッションを700(所有者のみ、読み取り、書き込み、削除が可能)に変更
$ chmod 700 .ssh

# authorized_keysを作成
$ touch .ssh/authorized_keys

# ファイルパーミッションを600(所有者のみ、読み取りおよび書き込みが可能)に変更
$ chmod 600 .ssh/authorized_keys

キーペアのパブリックキーをコピー

以下のコマンドを実行してパブリックキーをコンピュータから取得します。

# パブリックキーをコンピュータから取得
$ ssh-keygen -y

# キーを持つファイルのパスを指定
Enter file in which the key is (/Users/****/.ssh/id_rsa): /path_to_key_pair/my-key-pair.pem

表示されたインスタンスのパブリックキー(※以下は例)の末尾の【キーペア名】を除いてコピーします。

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQClKsfkNkuSevGj3eYhCe53pcjqP3maAhDFcvBS7O6V
hz2ItxCih+PnDSUaw+WNQn/mZphTk/a/gU8jEzoOWbkM4yxyb/wB96xbiFveSFJuOp/d6RJhJOI0iBXr
lsLnBItntckiJ7FbtxJMXLvvwJryDUilBMTjYtwB+QhYXUMOzce5Pjz5/i8SeJtjnV3iAoG/cQk+0FzZ
qaeJAAHco+CY/5WrUBkrHmFJr6HcXkvJdWPkYQS3xqC0+FmUZofz221CBt5IMucxXPkX4rWi+z7wB3Rb
BQoQzd8v7yeb7OzlPnWOyN0qFU0XA246RA8QFYiCNYwI3f05p6KLxEXAMPLE

取得したキーペアのパブリックキーをペースト

以下のコマンドを実行して、コピーしたキーペアのパブリックキーを【authorized_keys】にペーストします。

#.ssh/authorized_keysを編集
$ vi .ssh/authorized_keys

デフォルトユーザ(ec2-user)を削除する場合

追加したユーザーアカウントでAWSのEC2にSSH再接続

以下のコマンドを実行してAWSのEC2にSSH再接続します。

$ ssh -i ~/.ssh/秘密鍵名.pem 追加したユーザーアカウント@パブリックDNS

ログイン完了

以下が表示がされたらログイン完了です。

Last login: Mon Jan 15 17:27:41 2018 from ***.***.***.***

       __|  __|_  )
       _|  (     /   Amazon Linux AMI
      ___|\___|___|

https://aws.amazon.com/amazon-linux-ami/2017.09-release-notes/

デフォルトユーザーの削除

以下のコマンドを実行してデフォルトユーザ(ec2-user)とそのホームディレクトリを削除します。

# ec2-userとそのホームディレクトリの削除
$ sudo userdel -r ec2-user

ブログ記事の転載になります。

続きを読む

【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>

まとめ / 反省点

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

続きを読む