富士そば 巣鴨店
富士そばアドベントカレンダー、今年も発見してしまったので2日目に参加させていただきます。
富士そばしゅき度としては、先日まで会社のお金でAWS re:Inventに参加しており、1週間ほどラスベガスにいたのですが、
滞在残り2日くらいになったころから、さて日本に帰ったら何を食べようかとか考えるまでもなく、まぁ富士そばしかないなと思う程度のものです。
というわけで、今回は巣鴨店です。
巣鴨店といえばクッソみたいに泥酔したときに流れ着くことが多く、信頼の終着点として心を置かせていただいている店舗です。
成田からそそくさと巣鴨店に向かうと、そこには衝撃の光景が。
まじかよ。かなしい。
でも駅の反対側に新店舗ができているようでした。
とりあえずよかった。そしてカレーカツ丼がある店舗なのもポイント高いですね。
新店舗だからかテーブル席があり、演歌ぐあいも完璧です。
今回注文したのは渋谷店でよく食している紅生姜ちくわ天そばにしました。
この邪悪さすら感じるビジュアル、最高ですね。
前日の夜から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に計算、集計をオフロードするなど
- Aurora -> Redshift
- 相変わらず pg_bigm と textsearch_ja がない
Concurrency
remove log buffer
- WAL Buffer -> buffer がいっぱいになるとワーカーが待たされる
- これがオーバーヘッドになると判断したらしいとか
- ワーカーが直接ストレージにアクセスする
- Durability tracking
- トランザクション管理
- なんだかわからなかったけど、すごそう
- WAL Buffer -> buffer がいっぱいになるとワーカーが待たされる
Checkpoint
- CheckPointがない
- Bufferがないからストレージ直接書き込み
- CheckPointがない
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
ストレージノードが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からオブジェクトをアップロードしても、
バケットポリシーが適用されないため、アップロードしただけではそのコンテンツは公開できません
(公開するためには、アップロード後にオブジェクトの権限を変更する必要があります)。
この問題を STS Assume Role を使って解決します。
以降、アクセスされる側を アカウントA
、アクセスする側を アカウントB
とします。
アカウントAにIAM Roleを作成する
IAM → Roles → Create Role → Another AWS account を選択して必要事項を入力。
作成する IAM Role は AllowPutToS3
という名前にします。
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 をすることも可能のようです。
とても便利そうですね。
boto3 で AssumeRole したクライアントを作成する実装例
を晒してみます。
微妙に client と resource を選択することができて便利な気がします。
ご査収くださいませ。
AWS Tools for PowerShell で S3 から指定した prefix のオブジェクトをダウンロードする
新しめの AWS Tools for PowerShell では Copy-S3Object
に -KeyPrefix
オプションがあるので、表題のことができそうです。
ツールのバージョンアップ
自分のローカルにインストールされていた Version 3.1**** には -KeyPrefix
オプションがなかったので、以下の手順でバージョンアップしてみます。
- プログラムと機能から AWS Tools for PowerShell を削除
- 管理者権限で起動した PowerShell で
Install-Module -Name AWSPowerShell
を実行- PowerShell version 5 以上
一度ターミナルを閉じてバージョンアップができたか確認します。
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 のオブジェクトをダウンロードする
というスクリプトを書いたので晒してみます。
$ 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
追記:
以上です!
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
便利ですね。