set setting reset

脂肪と糖にはたらくやつ

富士そば 巣鴨店

富士そばアドベントカレンダー、今年も発見してしまったので2日目に参加させていただきます。

adventar.org

富士そばしゅき度としては、先日まで会社のお金でAWS re:Inventに参加しており、1週間ほどラスベガスにいたのですが、
滞在残り2日くらいになったころから、さて日本に帰ったら何を食べようかとか考えるまでもなく、まぁ富士そばしかないなと思う程度のものです。

というわけで、今回は巣鴨店です。
巣鴨店といえばクッソみたいに泥酔したときに流れ着くことが多く、信頼の終着点として心を置かせていただいている店舗です。

成田からそそくさと巣鴨店に向かうと、そこには衝撃の光景が。

f:id:rriifftt:20181201201153j:plain f:id:rriifftt:20181201201224j:plain

まじかよ。かなしい。
でも駅の反対側に新店舗ができているようでした。

f:id:rriifftt:20181201204329j:plain

とりあえずよかった。そしてカレーカツ丼がある店舗なのもポイント高いですね。
新店舗だからかテーブル席があり、演歌ぐあいも完璧です。

今回注文したのは渋谷店でよく食している紅生姜ちくわ天そばにしました。
f:id:rriifftt:20181201202220j:plain この邪悪さすら感じるビジュアル、最高ですね。
前日の夜から20時間以上なにも食べずに富士そばを狙ってきたこともあり、秒で完食です。

秒だったので正直味とかよくわからなかったですが、この新巣鴨店はカエシが強くなく、やさしい系の出汁だったなーという印象です。
こういうのもいいけど、次は真っ黒なところに行こう、そんな風に思いました。

はい。 こちらからは以上です。

20181121. Aurora Architecture Night メモ

表題のイベントに参加してきました。 ハイパー殴り書きです。Auroraすげーくらいの感想しかなかった。

postgresql compatibility

  • pg10 に対応
  • RDS Snapshot -> Aurora Migration
  • 様々なExtensionをサポート
    • GIS
    • pgceypto
    • plpgsql
    • pg_hint_plan
    • postgres_fdw
    • dblink -> 関数として実装されている
      • Aurora -> Redshift
        • Redshiftに計算、集計をオフロードするなど
    • 相変わらず pg_bigm と textsearch_ja がない

Concurrency

  • remove log buffer

    • WAL Buffer -> buffer がいっぱいになるとワーカーが待たされる
      • これがオーバーヘッドになると判断したらしいとか
    • ワーカーが直接ストレージにアクセスする
    • Durability tracking
  • Checkpoint

    • CheckPointがない
      • Bufferがないからストレージ直接書き込み
  • Redoしない

    • ?

Vacuum

  • XID周回問題
    • CloudWatchにメトリクスがある
  • freeze map
    • 9.6から
    • VACUUMすべきタプルを管理
    • Aurora には Filesystem がない
      • ?
    • Intelligent VACUUM Prefech
      • VACUUMが86%速い

Scalability

  • 各AZに2つずつ、系6つのデーターのコピーを保持
  • master / repllica が同じストレージを参照している
  • Write のパフォーマンスが一定
  • クラッシュリカバリをストレージ側で行う

Auroraの新機能

  • Backtrack

    • 全てのログレコードを保持
      • LSN(Logical Sequence Number)が付与されている
    • ストレージ側が見せるブロック(LSN?)をヘッドノードに伝えることで制御している
    • 最大3日
    • 専用の領域を必要とするのでストレージ課金対象
    • 常に一貫性のある時間にBacktrackを行う
      • Votingが確定していることかな
  • Aurora Serverless

    • 完全マネージドな感じ
    • 設定とかできない
    • 軽いロードのDB向け
    • proxy endpoint -> Request Router -> NLB -> DB
    • ダウンタイムなしの自動スケールアウト
    • 0からスケール
      • 使わなければインスタンスだけ削除するという設定が可能
      • 超かっこいい
  • parallel query

    • クエリをストレージノードの数千のCPUにプッシュダウン
    • クエリを分解 -> 分解されたクエリにパラレルクエリコンテキストなるメタデータを付与
    • ストレージの台数分並列化する
      • 16並列まで?
  • Aurora Multi Master

    • Single Region Multi Master
    • Multi Region Multi Master
    • ダウンタイム0
      • アプリ側に対応が必要
    • conflict
      • 1つの条件でのみコンフリクト解消のプロセスが発動する
      • COMMIT先勝ち
      • パーティショニングすることがコンフリクトを軽減するために有効
    • Global replication physical
      • ちょっと何を言っているのか
      • 1sec以下の遅延
      • レプリケーション専用インフラが背後に自動で作成

Auroraのなかみ

  • キャシュレイヤーの分離
    • ヘッドノードにはいるが、DBプロセスにいない
  • カスタムエンドポイント

    • ヘッドノードのまとまりをつくれる
    • キャッシュの取り回しのために使うなど
  • Quoram

    • writerが6つのストレージノードに一斉に書き込み
    • 4つ以上のノードが完了したら、COMMITする
      • Vr + Vw > V
      • Vw > V/2
      • 少なくとも1つの共通のコピーを保持
      • 必ず重複するように
  • ストレージノードが10GBごとの論理ブロックに分割

    • なぜ10GBなのかはわからなかった
  • protection groupという単位
  • Auroraはクォーラムセットとエポックを使用
    • ノードの正常性が疑わしい状態になったらエポックが作成される
epoc1 abcdef

epoc2 abcdef(?)
      abcdeg(new)

epoc3 abcdef(NG)
      abcdeg(OK)
  • Auroraはデータページを全て送信することでレプリケーションしているわけではない
    • 差分のみを送っている

S3のクロスアカウント問題をSTS AssumeRole で解決する

背景

例えばアカウントAにある my-bucket という S3 バケットに対して、アカウントBのリソースからオブジェクトをアップロードした時に、
my-bucket に付与されているバケットポリシーが効かずにハマることがあります。

バケットポリシーでIPアドレス制限だけして他のアカウントのクレデンシャルからアップロードするようなケースです。

アカウントBからオブジェクトをアップロードした場合、
オブジェクトの所有者はアカウントB(バケット所有者のアカウントAとは別のアカウント)になるためバケットポリシーがオブジェクトに適用されません。
例えば、静的ウェブホスティングを有効にしているバケットに、アカウントBからオブジェクトをアップロードしても、
バケットポリシーが適用されないため、アップロードしただけではそのコンテンツは公開できません
(公開するためには、アップロード後にオブジェクトの権限を変更する必要があります)。

blog.serverworks.co.jp

この問題を STS Assume Role を使って解決します。
以降、アクセスされる側を アカウントA、アクセスする側を アカウントB とします。

アカウントAにIAM Roleを作成する

IAM → Roles → Create Role → Another AWS account を選択して必要事項を入力。
作成する IAM Role は AllowPutToS3 という名前にします。

f:id:rriifftt:20181102122453p:plain

external id は事前共有鍵のようなもの?。
一致しなければ認証エラーとなるものなので、取扱には注意が必要です。

なお、人間がAssumeRoleをして他AWSアカウントのリソースを触るのならば、セキュリティの観点から MFA を利用した方がよいでしょう。
今回はシステム的にアクセスをしたいので、MFAではなく external id のみで進めてみます。

また、このウィザードからは1つのアカウントしか登録できないので、複数登録したい場合はウィザード完了後にポリシーを編集する必要があります。

IAM Policy

作成した AllowPutToS3 Role に Policy をアタッチします。
今回は S3 への Put のみを許可するポリシーとします。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowPutToS3",
            "Effect": "Allow",
            "Action": "s3:PutObject",
            "Resource": "arn:aws:s3:::my-bucket/*"
        }
    ]
}

Trust relationships

IAM Role を触ることができるアカウントを指定します。
Trust relationships タブ から Edit trust relationships を選択し、以下の様に設定します。
複数のアカウントから許可したい場合は、ここでアカウントIDを指定することで増やすことができます。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": [
          "arn:aws:iam::アカウントBのアカウントID:root",
        ]
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "sts:ExternalId": "hoge"
        }
      }
    }
  ]
}

アカウントBからAssume Roleする

IAM Policy の設定

my-bucket をさわりたいアカウントBのリソースに以下の様なPolicyを設定します。
IAM UserでもGroupでもIAM Roleでもなんでもいいです。

{
    "Action": "sts:AssumeRole",
    "Effect": "Allow",
    "Resource": "arn:aws:iam::アカウントAのアカウントID:role/AllowPutToS3"
}

Credential の取得

上記の IAM Policy が設定されたリソースから Credential を取得します。
以下は AWS CLI での例です。

$ aws sts assume-role \
    --role-arn arn:aws:iam::アカウントAのアカウントID:role/AllowPutToS3 \ 
    --role-session-name hoge \ # セッションに付与する任意の名前
    --external-id hoge # IAM Role に設定した内容と一致しなければエラー

以下の様なレスポンスが返ってきます。

{
    "AssumedRoleUser": {
        "AssumedRoleId": "**************************",
        "Arn": "arn:aws:sts::アカウントAのアカウントID:assumed-role/******************"
    },
    "Credentials": {
        "SecretAccessKey": "*************",
        "SessionToken": "******************************************************************************************",
        "Expiration": "2018-03-05T04:45:01Z",
        "AccessKeyId": "******************"
    }
}

この認証情報をつかってオブジェクトを Put すると、他アカウントからのアクセスでもバケットポリシーが効くようになります。
ややこしいけど便利ですね。

AWS CLI では .aws/config などに必要な設定をすることで自動的に AssumeRole をすることも可能のようです。
とても便利そうですね。

dev.classmethod.jp

boto3 で AssumeRole したクライアントを作成する実装例

を晒してみます。
微妙に client と resource を選択することができて便利な気がします。

gist.github.com

ご査収くださいませ。

AWS Tools for PowerShell で S3 から指定した prefix のオブジェクトをダウンロードする

新しめの AWS Tools for PowerShell では Copy-S3Object-KeyPrefix オプションがあるので、表題のことができそうです。

ツールのバージョンアップ

自分のローカルにインストールされていた Version 3.1**** には -KeyPrefix オプションがなかったので、以下の手順でバージョンアップしてみます。

  • プログラムと機能から AWS Tools for PowerShell を削除
  • 管理者権限で起動した PowerShellInstall-Module -Name AWSPowerShell を実行

一度ターミナルを閉じてバージョンアップができたか確認します。

PS C:\> Import-Module AWSPowerShell
PS C:\> get-Module AWSPowerShell

ModuleType Version    Name                                ExportedCommands
---------- -------    ----                                ----------------
Binary     3.3.283.0  AWSPowerShell                       {Add-AASScalableTarget, Add-ACMCertificateTag, Add-ADSConf...

3.1.**** からバージョンアップできました。

やってみる

こんな感じのバケットがあるとして

PS C:\> (Get-S3Object  -BucketName my-bucket -Prefix test).Key
test/hige_hoge.txt
test/hoge_hige.txt
test/hoge_hoge.txt

以下の様に実行します。

PS C:\test> Copy-S3Object -BucketName my-bucket -LocalFolder . -KeyPrefix test

Mode                LastWriteTime         Length Name
----                -------------         ------ ----
d-----         6/4/2018   3:28 PM                test

PS C:\test> ls


    Directory: C:\test


Mode                LastWriteTime         Length Name
----                -------------         ------ ----
-a----         6/4/2018   3:28 PM              0 hige_hoge.txt
-a----         6/4/2018   3:28 PM              0 hoge_hige.txt
-a----         6/4/2018   3:28 PM              0 hoge_hoge.txt

いい感じです。
が、↓のようにファイル名の一部まで prefix を指定しようとすると、うまくダウンロードできませんでした。

PS C:\test> Copy-S3Object -BucketName my-bucket -LocalFolder . -KeyPrefix test/hoge


Mode                LastWriteTime         Length Name
----                -------------         ------ ----
d-----         6/4/2018   3:30 PM                test


PS C:\test> ls

ちょっと残念。

boto3 で S3 から指定した prefix のオブジェクトをダウンロードする

というスクリプトを書いたので晒してみます。

gist.github.com

$ python download_s3_objects.py --help
Usage: download_s3_objects.py [OPTIONS]

Options:
  -p, --profile TEXT
  -b, --bucket-name TEXT
  -d, --destination TEXT
  -P, --prefix TEXT
  --help                  Show this message and exit.

こんな感じでファイルが格納されているとして

$ aws s3 ls s3://my-bucket/test/
2018-06-04 14:46:19          0 hige_hoge.txt
2018-06-04 14:46:26          0 hoge_hige.txt
2018-06-04 14:46:23          0 hoge_hoge.txt

以下の様に使います。

$ python download_s3_objects.py --bucket-name my-bucket --prefix test/hoge
downloaded ./hoge_hoge.txt
downloaded ./hoge_hige.txt

なお、新しめの powershell なら Copy-S3Object コマンドレット一発でできそうです。

AWS Tools for PowerShell Reference

追記:

rriifftt.hatenablog.com

以上です!

list を CSV っぽく置換する

python バージョンは

>>> sys.version
'3.6.2 (default, Oct  5 2017, 11:51:36) \n[GCC 4.2.1 Compatible Apple LLVM 9.0.0 (clang-900.0.37)]'

です。
やりたいことは

l = ['aoba', 'nene', 'hotaru']

といったリストを

'aoba','nene','hotaru'

というふうにしたい。 (例えば SQL の IN 句を生成したい時など)
単純に join すると先頭と末尾に ' が付与されない。

>>> print("','".join(l))
aoba','nene','hotaru

しかたなく format を使います。

>>> print("'{}'".format("','".join(l)))
'aoba','nene','hotaru'

こんなんでいいのかわからないけど、やりたいことはできました。

A client error (AuthFailure) occurred when calling the DescribeInstances operation: AWS was not able to validate the provided access credentials

はじめに

何気なく awscli を叩いたら表題のエラーが出たので調査しました。

つい先日当該アカウントの IAM User 棚卸しをしてアクセスキーの整理をしたのでその影響だろうと思われました。
当該インスタンスには IAM Role が付与されてはいたものの、実際はローカルに残存していたアクセスキーで API を叩いているのでは?という状況です。

環境

  • EC2
  • CentOS 6.7
  • やりたい操作を許可する IAM Role 付与済み

調査

まず、アクセスキーが残存しているのだろうと思い、 ~/.aws/credentials を確認。
たしかに鍵の記述があったのでそれを削除。ただ、依然としてエラーのまま。

よくわからないためぐぐると awscli には --debug オプションがあることがわかり、早速実行すると以下のメッセージを発見。

MainThread - botocore.credentials - INFO - Found credentials in boto config file: ~/.boto

なるほどと ~/.boto を確認すると、こちらにもアクセスキーが記述されていました。

対応

~/.boto を削除してエラーが解消されました。

さいごに

--debug 便利ですね。