Route 53
進化を理解するために、まずは古い方から見ていく。2016年の資料。
* パブリックホストゾーン（＝インターネット公開）とプライベートホストゾーン（＝VPC内のやつ）それぞれで利用可能。
* トラフィックルーティングと称して、従来型のDNSでの静的なルーティング（e.g. www.example.comにきたら1.1.1.1を応答）だけでなく、送信元が日本の場合は東京リージョンへ、そうでない場合はレイテンシーが最も小さいリージョンへ転送、のようなこともできる
* 他にもヘルスチェックの結果に応じてルーティングを変えたり、エンドポイントごとに重み付けしてルーティングを変えたりできる
* ヘルスチェックが誤って設定されている場合にはAWSに申し出て停止させることもできる（＝他人が自分のリソース環境にヘルスチェックをかけてきてるときの対処が可能）
* 従来の無味乾燥なレコード設定の他、トラフィックフローを使用することでエディターで編集できる（画面キャプチャーを見る限り、Node-REDみたいな見た目）
* 料金はホストゾーンごとに最初の25ホストゾーンは$0.50/月、トラフィックフローは$50/月、標準的なDNSクエリは10億クエリで$0.40
今まで、ドメインを購入したところのDNSを使うことが多くて、なんでDNSに登録するのに金かかるねん、って思ったけれど、標準的な内容だと小さな規模のうちは数ドル/月程度だから別に騒ぐような話じゃなかった。それよりも、その辺のDNSの機能に加えた付加価値がいくつもあって、そこで利便性を提供・儲けの機会を創出してるのがすごいなと思った。
続いて2019年の資料。
DNSサーバーとはそもそも何をするものか、の説明があって優しい。機能は次の4つ、の前に前提知識として、次の2つ。
* 反復問い合わせ：自らがネームサーバーを辿る際に行う問い合わせ
* 再起的問い合わせ：問い合わせ先に反復問い合わせを依頼する問い合わせ
上記を踏まえて次の4機能。
* ネームサーバー / Name Server：保有している情報の範囲で名前問い合わせに答える
* フルサービスリゾルバー / Full Service Resolver：反復問い合わせする、フルサービスリゾルバーが反復問い合わせを受け取った場合は反復問い合わせせずに保有している情報の範囲で回答する
* スタブリゾルバー / Stub Resolver：DNSクライアント実装で再帰的問い合わせをする、分かりやすい例がdigコマンド
* フォワーダー / Forwarder：受け取った問い合わせをルールに基づいて中継する
企業のネットワークのDNSサーバーの構成は、ネームサーバー、フルサービスリゾルバー、フォワーダーが同居してDNSサーバーとして成り立っているものが多いとのこと。ただしそれは、著名な実装がそうなっているからで、意図しているわけではないこともしばしばある様子。
で、内容は読み通してみたけど、理解度が低い人（＝ぼくです）は、この内容を噛み砕いてくれている、クラスメソッドのブログの方がしっくりくるかもしれない。
DynamoDB
DynamoDBの祖先は、Amazon.comでRDBMSのスケール限界を超えるために開発されたDynamoとのこと。
論文も読めた。
Dynamo: Amazon’s Highly Available Key-value Store
改めてDynamoDBは次の特徴を持つ。
* フルマネージド型のNoSQL DBサービス
* スケーラブルで低レイテンシー
* 高可用性で3x レプリケーションとってる
* APIも豊富
* ストレージの容量制限がない
DB系の文脈では時々出てくる結果整合性が特徴で、Readの時にはデフォルトだと最新の書き込み結果が即時に読み取り処理に反映されない可能性がある。
整合性のある読み込みをする場合はCapacity Unitを2倍消費するということで、通常よりも金がかかる。
ユースケースとしては、KVSとしてはもちろん、広告やゲームのユーザー行動履歴のDBとして使われることやモバイルアプリから直参照可能なバックエンドのデータベースとして使われたりもするらしい。
WebAPIとして使うこともできるし、SDKを介することもできて、対応している言語もそれなりにある。（Java, Python, PHP, .NET, Ruby, NodeJS, JavaScript, iOS, Android）
DynamoDB Accelerator（DAX）をアプリとDynamoDBの間に置くことで、キャッシュを保持させたりDynamoDBのテーブル状況にも対応している、とのこと。（テーブル状況に対応、って言葉として不明瞭には感じた。少し後に追加説明の絵があったけどこれは当日の説明がないと理解が厳しそう）
その他
これ見た瞬間に、あ、資料読んでよかった、と思った。
ECSの立ち位置を全く正しく理解できていなかったことがわかった。
出所：[AWS Black Belt Online Seminar] Amazon Elastic Container Service (Amazon ECS) 資料及び QA 公開 | Amazon Web Services ブログ https://aws.amazon.com/jp/blogs/news/webinar-bb-amazon-ecs-2020/p.13
雑な説明をすればコンテナ自体はEC2かFargateの環境上に払い出されて実行されるのであって、その指示をECSを通じて実施するような格好。
Fargateはコンテナの稼働時間に応じた課金で、管理項目がさらに減っていて、EC2よりも楽ができる雰囲気を感じた。
あとは、たまたま目について読んでてこれ面白かった。
AWSっぽくないというか、一般的な開発で使われるパターンに照らしながらAWSのサービスを使うと、みたいな話の展開の仕方の資料ってあんまり見たことなかった。
個人的にはこういうやつが好き。
[AWS Black Belt Online Seminar] AWSにおけるマイクロサービスアーキテクチャ設計パターンと実装
ところで、SlideShareの運営が変わるみたいだけど、こういうブログに埋め込むの今後どうするか考えた方がいいかもしれないなあ。しばらくは様子見する必要ありそう。