キャッシュ戦略

今日は友達家族の家に遊びに行きました。子どもたちは楽しく遊んでいました。

AWS ElastiCache を勉強しようと思いましたが、そもそもキャッシュ戦略を理解していなかったのでメモ。

そもそもキャッシュ戦略って何？

キャッシュにいつデータを保存して、いつ更新・削除するかを決めるルール

種類

一般的に、以下のキャッシュ戦略がある。
つまり、読み込み時と書き込み時で方針がいくつかあり、組み合わせる必要がある。

読み込み時の戦略

アプリが DB からデータを取得する（読み込む）ときにキャッシュにデータを保存するケース。

• Cache Aside (Lazy Loading)
• Read Through

書き込み時の戦略

アプリが DB にデータを作成・更新・削除する（書き込む）ときにキャッシュのデータもそろえるケース。

• Write Through
• Write Behind (Write Back / Lazy Write)
• Write Around
• Refresh Ahead

Cache Aside (Lazy Loading)

アプリはまずキャッシュにアクセス。
キャッシュに欲しいデータが無ければ、アプリは DB から取得して、さらにキャッシュにも保存。

Cache-Aside パターン - Azure Architecture Center | Microsoft Learn

Read Through

アプリはキャッシュだけを参照して、キャッシュが DB からデータを自動で取得。

What is Read-Through vs Write-Through Cache?

Read-Through vs Write-Through Cache - by Stephane Moreau

Write Through

アプリが DB のデータを更新するときに、キャッシュも同時に更新する。
ざっとググると、アプリがキャッシュだけにアクセスする例もあれば、キャッシュとDB両方にアクセスする例も見られた。

What is Read-Through vs Write-Through Cache?

Database caching: Overview, types, strategies and their benefits.

Write Behind (Write Back / Lazy Write)

アプリはまずキャッシュのデータを更新して、後から DB へ非同期で反映する。

Database caching: Overview, types, strategies and their benefits.

Write Around

アプリは DB のデータを更新する。

※え、じゃあキャッシュへのデータ保存はいつ？
→「参照時にキャッシュになければ DB からデータを保存する」としている記事がいくつかあり、つまり Cache Aside との併用が前提なのかなと思いました。

Write-through, write-around, write-back: cache explained | Computer Weekly

Caching Strategy: Write-Around Pattern

Refresh Ahead

キャッシュ期限前にバックグラウンドのジョブなどで更新する。
つまり、キャッシュミスを極力避けたい場合の戦略。

※キャッシュへの初回データ保存は、たぶん他の戦略と組み合わせるんだと思う。

Caching Strategy: Refresh Ahead Pattern

その他のとても参考になる記事

soudai.hatenablog.com

S3 アクセスポイント

今日は曇りだったので公園で遊びました。ボールを追いかけたり山登りしたりしました。お昼寝もちゃんとできました。

S3 バケットポリシー

普通、 S3 バケットへのアクセス制御は、バケットポリシーで行う。
しかし、同じ S3 バケットをいろんなユーザーやアプリで使う場合、バケットポリシーが複雑になってしまう。

S3 アクセスポイントは、S3 オブジェクトにアクセスするための新しい入り口。
この入口には、アクセスポイントポリシーを定義して、アクセス制御が行える。
（バケットポリシーと同じように、誰がどのオブジェクトにどんな操作をできるかを定義できる。）

この入口を、ユーザーやアプリごとに用意することで、入り口を個別に用意できる。
その結果、バケットポリシーが複雑になってしまうのを回避できる。

docs.aws.amazon.com

アクセスポイントポリシー

アカウント 123456789012 の IAM ユーザー Suzukiに、
アカウント 123456789012 のアクセスポイント my-access-point を介して、
プレフィックスが Suzuki/ であるオブジェクトを 、
GET および PUT するアクセス許可を付与する例。

{
    "Version":"2012-10-17",
    "Statement": [
    {
        "Effect": "Allow",
        "Principal": {
            "AWS": "arn:aws:iam::123456789012:user/Suzuki"
        },
        "Action": ["s3:GetObject", "s3:PutObject"],
        "Resource": "arn:aws:s3:ap-northeast-1:123456789012:accesspoint/my-access-point/object/Suzuki/*"
    }]
}

ここで注意なのが、バケットポリシー側では以下のいずれかのアクセス制御を行う必要がある。

• アクセスポイント経由でアクセスすることを許可（推奨）
• アクセスポイントポリシーと同じアクセス許可

docs.aws.amazon.com

VPC 限定版とインターネット版

S3 アクセスポイントには、VPC 限定版とインターネット版があり、作成時に選択する。

VPC 限定版の場合は、特定の VPC のみからアクセスできる。
インターネット版の場合は、インターネット経由でアクセスできる。

ここで注意なのが、VPC 限定版の場合、以下のようにアクセスする。

EC2
Lambda
ECS
  │
  ▼
VPC Endpoint
  │
  ▼
VPC Access Point
  │
  ▼
S3 Bucket

つまり、VPC エンドポイントを先に通る。 ということは、VPC エンドポイントポリシーでもこの経路を許可する必要がある。 具体的には、

アクセスポイントおよび基となるバケットの両方へのアクセスを許可

Virtual Private Cloud に制限されたアクセスポイントの作成 - Amazon Simple Storage Service

アクセスポイントへのアクセスだけでなく、バケットへのアクセスも、エンドポイントポリシー上では許可する必要があるようです。

ブロックパブリックアクセス設定はどうする？

ブロックパブリックアクセス設定はオンで問題なさそう。

注意点

オブジェクト操作のみ対応。
バケット作成・削除などの管理操作には利用できない。

S3 へのアクセス権

この前の日曜日に近くの川に水遊びをしてきました。とても楽しそうでした。

S3 へのアクセス権制御の仕組みがあやふやすぎたので調べました。
アイデンティティーベースのポリシー（IAM）とリソースベースのポリシー（バケットポリシー）が対象です。

2つを合わせた評価ロジック

• いずれか一方で Deny なら、アクセス拒否
• 両方で Allow、もしくは片方で Allow （もう一方は Allow も Deny も明示なし）なら、アクセス許可

アクションがアイデンティティのポリシーかリソースベースのポリシー、または両方で許可されている場合、AWS はそのアクションを許可します。これらのポリシーのいずれかを明示的に拒否した場合、その許可は無効になります。

docs.aws.amazon.com

Allow も Deny も明示なし、の扱い

暗黙的な拒否 というそうです。
デフォルトのバケットポリシー（= 何も書かれていない）場合は、バケットポリシー単体では暗黙的な拒否、すなわちアクセス拒否されます。
（ここでもしIAMポリシーで Allow なら、上に記載の通り、アクセス許可されます。）

docs.aws.amazon.com

知らなかった…

以下のようなバケットポリシーのみを設定しているとします。このポリシー単体としては、vpce-yyyyy からのアクセスは拒否されますか？
↓
明示的な拒否ではないが、暗黙的な拒否になる。
もし IAM ポリシーで許可されている場合、vpce-yyyyy からのアクセスは許可される。
もっと言うと、IAM ポリシーで許可されているなら、インターネット経由でのアクセスもできてしまう。（な、なんだってー！）

{
  "Effect": "Allow", 
  "Principal": "*",
  "Action": "s3:*",
  "Resource": [
    "arn:aws:s3:::my-bucket",
    "arn:aws:s3:::my-bucket/*"
  ],
  "Condition": {
    "StringEquals": { 
      "aws:SourceVpce": "vpce-xxxxxxxx"
    }
  }
}

ではアクセス制御は Deny で考えるのが良い？

ように思えるけど、設定を誤ると誰もアクセスできないゾンビバケットになるらしい。

techblog.nhn-techorus.com

なので、注意してつけるべきみたい。

アクセス制御が正しく設定できているか不安になる…

こんなときに、チェックできるのが IAM Access Analyzer for S3 らしい！！！

docs.aws.amazon.com

とても参考になる他の記事

S3の権限まわりの話 - サーバーワークスエンジニアブログ

AWS S3のセキュリティ早見表：IAM、バケットポリシー、ACL | SkygateBlog

S3の権限をマトリックスで整理する（IAM、バケットポリシー、ブロックパブリックアクセス、ACL、静的ウェブサイトホスティング） #AWS - Qiita

AWS ALB のノードやら ENI やら

昨日今日とサンリオピューロランドに行ってきました。パチンコやってるバッドばつ丸見れて最高でした。

AWS ALB の実体が理解できず調べました。が、結局理解できていないですが、見たサイトだけでもメモします

Load Balancer Node が登場

ELBは複数のノードで構成される。AZに ⼀つ以上ノードがあり、ノードごとにIP アドレスを持つ...。ELBの FQDNを名前解決すると、複数のAレコー ドが返却される。

なるほど、AZにノードが用意されてしかもIPアドレスを持つと。
他ページでも同じようなことに言及。

ELBの名前解決を⾏うと、複数のAレコードが返る。それぞれのIPアドレスは、ELBのノードを⽰し ており、それらはELBをデプロイしたAZのどれかに属している。クロスゾーン負荷分散を有効にする と、AZ Aに属しているノードが、別のAZにトラフィックをルーティングするようになり、全体の負 荷をより均等にすることができる。

https://pages.awscloud.com/rs/112-TZM-766/images/AWS-Black-Belt_2023_Elastic-Load-Balancing_0525_v1.pdf

以下でも同じようなことに言及。

ロードバランサー用のアベイラビリティーゾーンを有効にすると、Elastic Load Balancing はアベイラビリティーゾーンにロードバランサーノードを作成します。

Elastic Load Balancing の仕組み - Elastic Load Balancing

ENI も登場する

Elastic Load Balancing は、ロードバランサーを設定したサブネットにネットワークインターフェイスを作成します。

Application Load Balancer - Elastic Load Balancing

ENI がサブネットに用意されるとのことです。
ENI って IP アドレス持ってますよね。
ということは、前述のノードにこの ENI がアタッチされているということ？

以下の14ページにも、この ENI を経由して配下の EC2 にアクセスしている図があります。

https://pages.awscloud.com/rs/112-TZM-766/images/AWS-Black-Belt_2023_Elastic-Load-Balancing_0525_v1.pdf

ENI の IP を確認して、さらに増減することに言及した記事がこちら。

Application Load Balancer起動直後のENIを観察してみた | DevelopersIO

結局？？

たぶん ENI はノードに関連付けられている。ALB 宛てのリクエストは ENI の IP アドレスに解決されるので、ノードがこれを受け取り、配下の EC2 たちに割り振るのかな…

AWS Auto Scaling の権限

頭が天井に付くのがおもしろいらしく、高い高いするともっと上げろとせがまれます。

AWS ではすべての操作に権限が必要です。
Auto Scaling も EC2 を起動したりするのでそのための権限が必要なはず、でもどこで権限を Auto Scaling 自体に付与するのか？
Auto Scaling グループの設定とかではロール指定できなさそうだけど…

となったので調べました。

AWSServiceRoleForAutoScaling ロールが自動で付与される

らしいです。

まずこのロールは、Auto Scaling が EC2 や ELB、CloudWatch などを操作するための AWS マネージドポリシー AutoScalingServiceRolePolicy が付与されています。
そしてこのロールは、Auto Scaling の初回作成時に自動で作成されます。
さらにこのロールは、Auto Scaling だけが呼び出せるようになっているようです。
（サービスリンク型ロールというらしい）

なおこのロールの権限設定や名前は変更不可とのこと。

ということでちゃんと権限があることを確認できました。

docs.aws.amazon.com

CloudWatch テレメトリ設定

今日はじーじばーばの家に遊びに行きました。長靴も買いました。

CloudWatch テレメトリ設定

AWSリソースのうち、メトリクスやログ取得がちゃんとできているのがどれか、漏れているのはどれか、を管理できる機能。
すなわち、監視できているリソースとできていないリソースを確認できる機能。
（リソースをいっぱい作ると、監視できていないものが出てきてしまう。のを、解決できる。）

• どのリソースにどんな監視を行うか、というルールを用意して自動で適用もできる！
  ⇒ 新しく作ったリソースの監視漏れが防げる！
• AWS Organizations と連携して、メンバーアカウントのテレメトリ設定をマスターアカウントで管理することもできる！

例えば、とあるメトリクスで追跡できる障害を防ぐために、

1. そのメトリクスの監視を必須とするルールを作成する
2. 複数アカウントあるなら、Organizations と連携して全アカウントでルール適用する

といった、ことができそう

AWS S3 静的ウェブサイト公開

保育園でうさぎを飼い始めたのでとても嬉しそうです。うさぎさん見に行こうと言うと、ホイホイ片付けしてくれます。

S3 で静的ウェブサイト公開する手順を理解するためのメモ。

ざっくり手順

1. S3 バケットにindex.htmlを置く！
2. S3 バケットの「静的ウェブサイトホスティング」を有効！
3. S3 バケットの「ブロックパブリックアクセス設定」を無効！
4. S3 バケットのバケットポリシーで許可！

とても参考になる記事
techblog.ap-com.co.jp

CloudFront を前段に配置するよねよく

この手順も上記記事を見ましょう。

CloudFront の OAC もよく見かけるけど？

「ブロックパブリックアクセス設定」を有効にして基本的に外部から S3 への直接アクセスを防ぎつつ、CloudFront 経由でのみ S3 にアクセスさせたいときに使います。

公式
Amazon S3 オリジンへのアクセスを制限する - Amazon CloudFront

参考手順1
[NEW] CloudFrontからS3への新たなアクセス制御方法としてOrigin Access Control (OAC)が発表されました！ | DevelopersIO

参考手順2
OACによるCloudFrontからS3への接続制御: Route53とACMを用いて、独自ドメインで静的サイトをホストする | NHN テコラス Tech Blog | AWS、Google Cloudなどのインフラ技術ブログ

手順としては理解できたのですが、そもそも「バケットポリシーも必要なはずで、何で OAC も必要なのか？」がよく理解できてなかったです。 で、調べてみました。

そもそも CloudFront には、サービスロールがつけられない

Amazon CloudFront と IAM との連携方法 - Amazon CloudFront

IAMロールとかつけられるなら「誰がアクセスしたか」を判断できます。 しかし、CloudFront にはつけられないので、アクセス先である S3 からすると「誰からのアクセスか」がわからないらしい。

IAMロールの代わりを OAC が担う

OAC is based on an AWS best practice of using IAM service principals to authenticate with S3 origins.

Amazon CloudFront introduces Origin Access Control (OAC) | Networking & Content Delivery

IAM の機能を OAC が担うのだと理解しました。 OAC により、「これは特定 CloudFront からのアクセスである」と S3 が判断できるということですきっと。 「OAC により、認証付きリクエストを S3 に送れるよ」と以下にも記載ありました。

CloudFront provides two ways to send authenticated requests to an Amazon S3 origin: origin access control (OAC) and origin access identity (OAI).

Restrict access to an Amazon S3 origin - Amazon CloudFront