AWS の Web まわりをシーケンス図で表現してみた

# はじめに

* PlantUML の復習中（IntelliJ IDEAで書いてる）
* UML 自体の復習中ともいう
* AWS を利用した場合の素敵構成をシーケンス図にしてみた
* 構成自体は出来てるけど本番運用されていないのでコストがいまいち見えてない（開発機しか走っていない）
* サーバレスとかマイクロサービスとか言ってる時代に今更モノリシックかよとか言わないでｗ

# シーケンス図

![sequence_aws_front.png](https://qiita-image-store.s3.amazonaws.com/0/44420/16c97435-9a1e-fe0f-6334-e41ec2df913e.png)

# 説明（ちまちま追記予定。メリデメを特に。。。）

## サービス説明（AWSの）

* [Route 53](https://aws.amazon.com/jp/route53/) : Amazon Route 53
    * DNSサービス。
    * ドメイン取得、SSL証明書取得、運用までACMとセットで大変便利
    * AWS上のリソースに向ける場合、[Aliasレコード](http://dev.classmethod.jp/cloud/aws/amazon-route-53-alias-records/)を使うことで高速化
* Client
    * これはサービスじゃなくてリクエストする人（PCとかスマホとか）
* [CloudFront](https://aws.amazon.com/jp/cloudfront/) : Amazon CloudFront
    * CDN サービス
* [ACM](https://aws.amazon.com/jp/certificate-manager/) : AWS Certificate Manager
    * SSL/TLS 証明書の管理
* [WAF](https://aws.amazon.com/jp/waf/) : AWS Web Application Firewall
    * ウェブアプリケーションファイアウォール
* [S3](https://aws.amazon.com/jp/s3/) : Amazon Simple Storage Service
    * ストレージ
* [ELB](https://aws.amazon.com/jp/elasticloadbalancing/) : Elastic Load Balancing
    * ロードバランサー
* [EC2](https://aws.amazon.com/jp/ec2/) : Amazon Elastic Compute Cloud
    * 仮想サーバ

## メリット

* やってみれば驚くほど簡単
* なるほどインフラエンジニアじゃなくてもできそう（できる）
* 特に新規案件等でドメイン取得から始める場合のワンストップ感は楽すぎてやばい
    * それをロックインと呼ぶならまぁそうね、としか。。。
* 組み換え、スモールスタートが容易
    * R53+S3 （静的コンテンツ配信）
    * R53+EC2（動的コンテンツ配信）
    * R53+ELB+EC2（サーバスケール。ASG）
    * R53+ELB+ACM+EC2（SSL対応）
    * R53+CloudFront+ACM+ELB+EC2(CDN対応)
    * R53+CloudFront+ACM+S3+ELB+EC2(静的コンテンツをEC2が処理しない)
    * R53+CloudFront+ACM+WAF+S3+ELB+EC2(セキュリティ対応)
    * 実際こんな感じで差し込んで作っていけるので、常に動作確認しながら進められる
        * 初心者にはとてもありがたい
        * あまりおすすめではないけど外形監視で静的コンテンツと動的コンテンツをチェックしたままにするとTDDっぽいｗ
* 使った分だけ払い
    * コスト増とは相反するけど、同等の機能をオンプレで用意とか考えたくない
    * ざっと作ってテストして終わったら削除して、ってできれば、びっくりするほど安く遊べる
* ほとんど全部クラスメソッドさんをはじめとするAPN企業さんのブログ等で簡単に学べる
    * 学習コストが低いのは大きなメリット
    * もっとも個人でならって話で、企業レベルで使い物になるレベルにするには結構かかる気がする
* CloudFront を使って http/2 対応が簡単
* CloudFront と ACM を使って https 対応が簡単かつ永続的

## デメリット

* ベンダーロックインが嫌な人には嫌な感じに映るかもしれない
    * ちゃんと理解してれば大きな誤解だとわかるはずだけど
    * AWS（というかクラウド）はサービスを組み合わせて環境構築するものなので、サービスを他のものに変えるのは簡単にできる
    * ただAWSにおいてはサービス間連携が容易になるようにできてるので組み合わせが便利すぎて他を差し込む余地があまりないだけ
* コスト増？
    * CloudFrontは高いとよく聞くので（まだ別の本番システムほど通信が発生していないのでよくわからない）
    * WAFも処理量によってはまずいことになるかも？
* ここには挙げていないこともいろいろ理解していないときつい（というかできない）
    * もちろんこれは他でもそうなので、正確にはデメリットではない
    * 単に表面的なことだけ知って理解したつもりになったら後出しでもっといろいろ必要になって泣くことになるだけ
    * 必要なサービス（このシーケンスのような構成を組むことができるなら当然知っているはずの）
        * [AWS Identity and Access Management (IAM)](https://aws.amazon.com/jp/iam/)
        * [Amazon Virtual Private Cloud (VPC)](https://aws.amazon.com/jp/vpc/)
        * [Auto Scaling](https://aws.amazon.com/jp/autoscaling/)
        * [Amazon CloudWatch](https://aws.amazon.com/jp/cloudwatch/)
    * 必須ではないけどセキュリティ的に必須にしたほうがいいサービス
        * [AWS CloudTrail](https://aws.amazon.com/jp/cloudtrail/)
        * [AWS Trusted Advisor](https://aws.amazon.com/jp/premiumsupport/trustedadvisor/)
    * 必須ではないサービス
        * [Amazon Relational Database Service (rds)](https://aws.amazon.com/jp/rds/)
        * [Amazon Aurora](https://aws.amazon.com/jp/rds/aurora/)
        * [Amazon ElastiCache](https://aws.amazon.com/jp/elasticache/)
* CloudFront のディストリビューションの反映が遅い（1変更15分くらい？）ので変更をテストするときにどうしても時間がかかる

# お願い

* （UML的な）図自体の改善提案
* （AWS的な）サービスの組み合わせ改善提案
* （構成的な）サーバレスやマイクロサービスでの構成案
* （別クラウド的な）GCP,Azure その他クラウドサービスでの代替案と構成
* 建設的な意見が欲しいです 

# 最後に

* 今やってる案件が終わったら次こそサーバレス考えたいｗ