概要
今更ながら気づいたのですが、実は1ヶ月経っていましたね。
まぁ、もうここまで来たら1ヶ月とかも関係ないですね。
タイトルももう大体とかつき始めて変わっちゃいました。
この記事を読んでくれてる方はこのダメ人間の堕落ぶりをみて、
反面教師にしていただければ幸いです。
さぁ！心を切り替えたところで、
ここからは確実に受かるということに目的をシフトしていきます。
受けるからには絶対に受からなきゃ意味ないですから。
…というわけでもう何日目かもよく分からないですけど、
とりあえず、勉強を進めていこうと思います。
模擬試験で出題された部分で残りの分野を整理していきます。
セッション情報の保持
AWSを利用してステートレスなWebアプリサーバーを稼働させているケースにおいて、
サーバーがダウンした際にセッションの情報を失ってしまうことは問題です。
また、AWSは頻繁にスケールインとアウトを繰り返すため、
セッション情報を失わないように考慮して設計することはとても大事…だそうです。
これを失わない様に稼働させるには以下サービスの機能が有効です。
RDS
Elasticache
AmazonDynamoDB
それではそれぞれの何が有効なのでしょうか？
◆RDS
まず、RDSでは複数のAZ間にインスタンスを作成することができます。
そのため、1つのAZで障害が発生しても別のAZ上でインスタンスは影響を受けません。
或いは切り替えることも可能ですね。
そして、トリッキーな方法ではありますが、RDSのMySQLインスタンスでは
memcached Pluginを利用することが可能です。
<参考>付録: MySQL データベースエンジンのオプション
https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/Appendix.MySQL.Options.html
これを利用することでmemcachedを使うのと同じ効果を得られます。
※ただし、Elasticacheよりも速度は劣るそうですが…
これは言うまでもないですね。セッションを保持するための機能です。
ただし、memcachedを利用した場合にはレプリケーション機能がないため、
アプリでのチューニングかロードバランシングを複数の行う
ソフトや仕組みを実装する必要があります。
◆AmazonDynamoDB
そもそもDynamoDBの仕組み自体がKVSの情報を複数のAZ間に保存することであるため、セッション情報を保持する必要がないということです。
もう少しだけ…詳しい情報を3日目の記事で触れています。
安全な方法でAWS APIを呼び出す方法
EC2にデプロイしているアプリケーションに安全に認証情報を渡すには
どうしたら良いのでしょうか？
認証といえば散々、勉強してきたIAM！ですね。
というわけで以下のような情報がAWSドキュメントに記載されていました。
<参考>Amazon EC2 の IAM ロール
http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html
仕組みとしては予めアプリケーションで利用するためのロールを用意しておきます。
そのロールに対してcurlのコマンドを使用してロールに対して定義した
アクションおよびリソースの許可を取得するといった形です。