##AWSを使った機能の分散
当たり前の話をするわけではないですが、クラウドサービスを使うということは如何に一極集中させず、分散管理するかという話になってきます。
昔はオンプレミスでサーバ管理をするよりも、インターネットのあちら側のクラウドに設置して、仮想化技術で一つのサーバのように見せておくことに価値がありました。
だが、現代において、それは最低条件であり、より機能が細分化され、単体サービスだった頃の問題点をいかに回避し、顧客へのサービスダウンを回避するのかという点を徹底的に考えられるようになりました。
今回は、どのように機能の分散配置するのか説明したいと思います。
##各機能の紹介と利用理由
細かい所はオミットしましたが、図のような構成になるのではないかと考えています。
さて、それぞれの機能とその利用理由ですが、以下の通りです。
###本番系
####Route53
DNSサーバ。他でドメインを取得していても、AWSでサービスを作るならこちらにDNSを切り替えて使ったほうが良いです。特にALBやSESなどはこちらを使わないとトラブルが起こりえます。
####CloudFront
コンテンツを配信する仕組みCDNです。最近はfastlyなどもありますので、一概にこちらが正しいわけではありませんが、すべてをAWSで設計するのでこうなりました。
####ALB（ApplicationLoad Balancer）
仮想上のロードバランサです。負荷分散装置ですが、高度な処理が可能です。EC2で標準設定できるのでシンプルに実装しています。
####EC2
言わずと知れた静的サーバです。サービスのオートスケールの要だといえるでしょう。これがないと始まりません。
####CloudWatch
監視システムです。無料でもそこそこ使えますが課金してからが本番です。今回はアラートを上げて、オートスケールするような仕組みを作るため、シェルの代わりに使っていく予定です。
####ElastiCache
静的なキャッシュサーバです。データベースやS3との間に設置して、EC2との間のI/Oスループットを向上させる予定です。
####RDS
リレーショナル・データベースサーバです。DBのメンテナンスや拡張は従来ではものすごく面倒でしたが、RDSのおかげで便利になりました。拡張も拡大もほぼ自動でいけます。今回はマスタースレーブ構成を組みます。採用するDBはAurora（MySQL）です。
####S3
シンプルストレージサービスです。あらゆるデータを保管しておくことができるストレージサービスです。静的なHTMLとCSSもおけるので、サーバレスでホームページを公開できます。
###管理・分析計
####Kinesis firehouse
ログの収集と適切なフォーマットへ変換する装置です。膨大なログが出る可能性があるので、こちらで処理を予定しています。ですが、GCPの方が良いかなと思っていたりしますが、データの転送量との兼ね合いですね。
####Lambda
サーバレスアーキテクチャです。Kinesisで処理したrowデータをRedshiftに中継するために使います。
####Redshift
データウェアハウスです。BIと組み合わせてデータを可視化します。もしかすると、ここはGCPの方が強いのでBigQueryになるかもしれません。
####Quicksight
AmazonのBIツールです。もし、AWSでBIをやるなら場合はこれを利用します。
####Athene
S3をSQLの構文で検索できるようにするサービスです。サーバレスアーキテクチャですが、これらを見ると、すべてBigQuery+αで処理できるかもしれないので、コストとの兼ね合いで冷静に考えたほうが良いかもしれません。
##実装上注意した点
今回のポイントはEnterpriseサービスなのでダウンは絶対に起きないようにするための強固な基盤を作るためにはどうしたら良いのか？という点に着目しました。
もちろん、システムの接続ポイントが増えると、増えただけ障害が発生するのですが、最近のクラウドサービスはリージョンでディザスタリカバリを作るなどすれば、システムで担保できるのでSLAを設けても十分対応できるでしょう。
ベンチャーであっても、大企業並みの強固なシステム基盤を構築できるのがAWSの大きな利点だと思いました。
##まとめ
次回後編では、他社の仕組みを参照しながら、各社ごとの哲学を読み解き、自社との違いを解説していきます。