とんちゃんといっしょ

Cloudに関する技術とか日常とかについて書いたり書かなかったり

OpenStack Erisを調べてみた

Chaos Engineeringを調べてるときに「OpenStackにもFault injectionでOpenStackを試験するプロジェクトがあるよ」と聞いたので調べてみた。

OpenStack Eris

docs.openstack.org

OpenStackに様々な負荷をかけて、OpenStackの性能改善やResilienceにするためのテストフレームワークや、テストスートを作るプロジェクト

  • Load Injection
  • Fault Injection

もできる(予定)

OpenStack Erisに関する情報

OpenStack Summit Sydney のフォーラムに2件あったと教えてもらった

Extreme/Destructive Testing

www.openstack.org

LCOO = Large Contributing OpenStack Operators

LCOO - OpenStack

フォーラムのディスカッション内容

  1. What sort of tests do you run today that are destructive in nature?
  2. What is your desired workflow for issues that come up?
  3. How do you determine success/failure of your testing scenarios?
  4. Do you publicly publish your results (if so where)?
  5. What KPI do you evaluate today?
  6. What workloads do you run and against what architectures?

sessionは3part

  1. References: Extreme testing is non-deterministic. Such testing generally is valid with the following reference.
  2. Test Suite: What test scenarios are we trying to get done?
  3. Frameworks & Tools: How do we enable the test suite?

etherpadはこっち https://etherpad.openstack.org/p/SYD-extreme-testing

フォーラムではどういうテストをするのかという議論が行われていたっぽい。 また、Rallyとは何が違うのかというQAがあったのもログに残っている。

- What is the difference between Eris and Rally? (From spec it looks the same) (boris-42)
   (samP) Discussion is here http://lists.openstack.org/pipermail/openstack-dev/2017-November/124156.html
   (gautamdivgi) 
We are looking for a solution/mechanism where there the capacity for
- Load generation (Control + Data Plane)
- Failure injection (all over the cloud)
- Data capture (all touch points - not just API requests)
- KPI calculation (all touch points - not just API requests)
- Most importantly - have one part "influence" the other (E.g. run failures or a sequence of failures based on system criteria like netstat session counts or free memory remaining)
Rally does load generation and there are failure injection hooks - but cannot participate in more complex feedback, monitoring & computation mechanisms.
Rally is used today to generate load. Definitely looking to contribute some plugins for load gen & metrics collections enhancements.

LCOO-Extreme Testing-QA-ERIS

www.openstack.org

ここではErisのデモ行われたらしいがフォーラムだったのでビデオはないらしい。

Erisのデモ用の手順

openstack-lcoo.atlassian.net

etherpadはこちら https://etherpad.openstack.org/p/LCOO-Extreme_Testing-QA-ERIS

os-faultsなどが使われるのかというQAのログが残っているがframeworkのプラグインにすればという話が出ている

Will Eris support os-faults in the future? https://github.com/openstack/os-faults
- Need for extensible pluggable framework for fault injection, e.g.
    - Define levels of redundancy within infrastructure and inject faults up to the maximum which can be tolerated given that amount of redundancy (e.g. 2 node failures in a 5-node cluster)
    - Use os-faults to test failure scenarios defined by Self-Healing SIG and ensure that self-healing works
- Preference for reusing existing projects if possible
- If not possible, include gaps analysis in the spec
Maybe split spec into smaller pieces?
Can some example results / demo be published so that people can start looking at Eris and get a feel for what it can do?

まとめ

2年前ぐらいの情報しか見当たらないので特に進展はなさそうなのでもしOpenStackにたいしてChaos Engineeringをするのであれば別のツールを使ったほうが良いかも知れない。

労働組合とエンジニアの対話会やってみた

先日自分主催で労働組合とエンジニアの対話会をやってみた。

事前に sli.do で質問を集めて、組合側にもソレを共有し、当日は最初に最近のキャリア施策に関する説明をしてもらったあと事前質問を元に質疑をしたがくっそ面白かった。 事前質問が想像はしていたけど結構刺々しくて苦笑い。

当日はあまり質問する人がいなさそうだったので、 主催者だけどはしゃいで質問しまくったのでちょっと反省してる。

後日(というかさっき)、当日の質疑で出た質問や提案を改めてメールで組合側に送ったので回答待ち。

いやー、おもしろかった。

このあとの回答とか展開に期待!

IIJのDNSフィルタリング?

週末に我が家のネットがおかしくなったので子どもたちからYoutubeが見られないと大層クレームを受け、 私もSlackに繋がらなくなり、Amazon Eco dotも反応しなくなり、何だこれと思いルータやONUの再起動をしても今ひとつなんともならず。

月曜日に帰宅後設定を見ても特に変更がないので障害かと思い調べてみても特に障害情報が上がっておらず困ってTwitterでつぶやいたところ

DNSフィルタリングなんて始めてるのな・・・

そんなわけでDNSフィルタリングされてないDNSを設定したところ

ひとまずこれで子供に怒られなくて済むようにはなったものの、一応切り分けをしてみた。

フィルタリングされたDNSの場合

slack.comへのアクセス

dig は通る。

% dig slack.com

; <<>> DiG 9.10.6 <<>> slack.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 705
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;slack.com.            IN    A

;; ANSWER SECTION:
slack.com.        20    IN    A    99.84.134.165

;; AUTHORITY SECTION:
slack.com.        97990    IN    NS    ns-166.awsdns-20.com.
slack.com.        97990    IN    NS    ns-1901.awsdns-45.co.uk.
slack.com.        97990    IN    NS    ns-606.awsdns-11.net.
slack.com.        97990    IN    NS    ns-1493.awsdns-58.org.

;; Query time: 4 msec
;; SERVER: 2404:1a8:7f01:b::3#53(2404:1a8:7f01:b::3)
;; WHEN: Tue Jul 02 21:26:08 JST 2019
;; MSG SIZE  rcvd: 191

tracerouteは通らない

% traceroute slack.com
traceroute to slack.com (99.84.134.165), 64 hops max, 52 byte packets
 1  192.168.1.1 (192.168.1.1)  2.305 ms  1.443 ms  1.207 ms
 2  chiba01-z03.flets.2iij.net (160.13.161.x)  3.436 ms  4.215 ms  4.982 ms
 3  chiba1-ntteast1.flets.2iij.net (160.13.161.25)  5.739 ms  7.775 ms  9.502 ms
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  *^C

twitter.comへのアクセス

なぜかTwitterも通らなくなる

% traceroute twitter.com
traceroute: Warning: twitter.com has multiple addresses; using 104.244.42.1
traceroute to twitter.com (104.244.42.1), 64 hops max, 52 byte packets
 1  192.168.1.1 (192.168.1.1)  3.188 ms  2.069 ms  1.245 ms
 2  chiba01-z03.flets.2iij.net (160.13.161.x)  10.634 ms  12.700 ms  16.098 ms
 3  chiba1-ntteast1.flets.2iij.net (160.13.161.25)  21.534 ms  20.587 ms  13.338 ms
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
^C

でもdigは反応あり

% dig twitter.com

; <<>> DiG 9.10.6 <<>> twitter.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15264
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 10, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;twitter.com.            IN    A

;; ANSWER SECTION:
twitter.com.        243    IN    A    104.244.42.65
twitter.com.        243    IN    A    104.244.42.1

;; AUTHORITY SECTION:
twitter.com.        4935    IN    NS    ns3.p34.dynect.net.
twitter.com.        4935    IN    NS    ns2.p34.dynect.net.
twitter.com.        4935    IN    NS    d01-02.ns.twtrdns.net.
twitter.com.        4935    IN    NS    c.r06.twtrdns.net.
twitter.com.        4935    IN    NS    ns4.p34.dynect.net.
twitter.com.        4935    IN    NS    d01-01.ns.twtrdns.net.
twitter.com.        4935    IN    NS    a.r06.twtrdns.net.
twitter.com.        4935    IN    NS    ns1.p34.dynect.net.
twitter.com.        4935    IN    NS    b.r06.twtrdns.net.
twitter.com.        4935    IN    NS    d.r06.twtrdns.net.

;; Query time: 5 msec
;; SERVER: 2404:1a8:7f01:b::3#53(2404:1a8:7f01:b::3)
;; WHEN: Tue Jul 02 21:27:09 JST 2019
;; MSG SIZE  rcvd: 279

google.comへのアクセス

googleは通る

% traceroute www.google.com
traceroute to www.google.com (172.217.26.4), 64 hops max, 52 byte packets
 1  192.168.1.1 (192.168.1.1)  2.922 ms  1.291 ms  1.186 ms
 2  chiba01-z03.flets.2iij.net (160.13.161.x)  3.250 ms  3.576 ms  3.562 ms
 3  chiba1-ntteast0.flets.2iij.net (160.13.161.21)  4.318 ms  6.603 ms  5.416 ms
 4  tky008lip30.iij.net (202.214.41.93)  5.959 ms  8.551 ms  8.190 ms
 5  tky008bb00.iij.net (210.130.142.89)  9.827 ms  12.476 ms  13.610 ms
 6  tky001bb10.iij.net (58.138.88.1)  13.059 ms  14.238 ms  12.825 ms
 7  tky001ix04.iij.net (58.138.100.62)  12.169 ms
    tky001ix02.iij.net (58.138.100.54)  12.029 ms  9.808 ms
 8  72.14.242.38 (72.14.242.38)  8.725 ms
    202.232.1.86 (202.232.1.86)  7.361 ms
    72.14.242.38 (72.14.242.38)  5.072 ms
 9  * * *
10  72.14.233.220 (72.14.233.220)  10.889 ms
    nrt20s02-in-f4.1e100.net (172.217.26.4)  8.486 ms
    108.170.242.161 (108.170.242.161)  12.765 ms

digもとおる

% dig www.google.com

; <<>> DiG 9.10.6 <<>> www.google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44530
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.google.com.            IN    A

;; ANSWER SECTION:
www.google.com.        260    IN    A    172.217.161.68

;; Query time: 4 msec
;; SERVER: 2404:1a8:7f01:b::3#53(2404:1a8:7f01:b::3)
;; WHEN: Tue Jul 02 21:29:31 JST 2019
;; MSG SIZE  rcvd: 59

フィルタリングされていないDNSの場合

slack.comへのアクセス

% traceroute slack.com
traceroute to slack.com (99.84.134.165), 64 hops max, 52 byte packets
 1  192.168.1.1 (192.168.1.1)  13.403 ms  10.315 ms  7.211 ms
 2  chiba01-z03.flets.2iij.net (160.13.161.x)  48.603 ms  39.201 ms  38.889 ms
 3  chiba1-ntteast0.flets.2iij.net (160.13.161.21)  41.529 ms  50.059 ms  41.740 ms
 4  tky008lip30.iij.net (202.214.41.93)  39.944 ms  48.148 ms  50.577 ms
 5  tky008bb00.iij.net (210.130.142.89)  52.023 ms  42.148 ms  62.208 ms
 6  tky001bb10.iij.net (58.138.88.1)  51.263 ms  55.101 ms  61.491 ms
 7  tky001ix15.iij.net (58.138.102.210)  57.440 ms  42.014 ms
    tky001ix11.iij.net (58.138.102.202)  35.866 ms
 8  210.173.176.188 (210.173.176.188)  37.971 ms  42.719 ms  38.336 ms
 9  52.95.30.171 (52.95.30.171)  52.017 ms
    52.95.30.183 (52.95.30.183)  56.138 ms
    52.95.30.169 (52.95.30.169)  41.881 ms
10  52.95.30.18 (52.95.30.18)  71.838 ms
    52.95.30.54 (52.95.30.54)  60.939 ms
    52.95.30.58 (52.95.30.58)  38.320 ms
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  server-99-84-134-165.nrt57.r.cloudfront.net (99.84.134.165)  30.975 ms  45.644 ms  30.776 ms

twitter.comへのアクセス

% traceroute twitter.com
traceroute: Warning: twitter.com has multiple addresses; using 104.244.42.1
traceroute to twitter.com (104.244.42.1), 64 hops max, 52 byte packets
 1  192.168.1.1 (192.168.1.1)  150.819 ms  88.796 ms  8.696 ms
 2  chiba01-z03.flets.2iij.net (160.13.161.x)  36.320 ms  39.820 ms  95.059 ms
 3  * chiba1-ntteast1.flets.2iij.net (160.13.161.25)  40.946 ms  47.746 ms
 4  tky008lip31.iij.net (202.214.41.97)  53.321 ms  57.417 ms  61.216 ms
 5  tky008bb01.iij.net (210.130.142.93)  50.467 ms  35.077 ms  27.107 ms
 6  tky001bb11.iij.net (58.138.88.5)  31.195 ms  42.001 ms  38.530 ms
 7  tky001ix15.iij.net (58.138.102.214)  37.889 ms  39.328 ms
    tky001ix11.iij.net (58.138.102.206)  40.044 ms
 8  210.173.176.152 (210.173.176.152)  29.130 ms  31.093 ms  27.638 ms
 9  * * *
10  104.244.42.1 (104.244.42.1)  31.713 ms  298.895 ms  180.441 ms

よくわからん。。。

一応公式には

宛先がレピュテーションデータに含まれている場合、IIJが別途用意するサーバのIPアドレスに宛先を置き換えることで、本来の宛先へアクセスしないようにします。

と書かれているので本来の宛先へアクセスはしてないわけであるが、Twitterを見ても私のように困ってる人もいないのでますます謎は深まる・・・

私はNWは全然強くないので会社の強い人に聞いてみると、どこかでルーティングが書き換えられてるか、単純に機器故障じゃないかといわれた。

何にせよ再び我が家に自由なインターネットが戻ってきたのでこんなもんにしておく。

やっぱりネットワーク良くわからん。。。。

frigga にみるNetflixのクラスタ命名規則とChaos Monkeyがkubernetes provider v2でうまく動かない理由

タイトルが長いけど簡単に言うと、Chaos Monkeyはk8s対応を謳ってますが k8s provider v2(Manifest)で Deployment などを使うと動かないことがあります。

github.com

Chaos Monkey should work with any backend that Spinnaker supports (AWS, Google Compute Engine, Azure, Kubernetes, Cloud Foundry). It has been tested with AWS, GCE, and Kubernetes.

理由はNetflixクラスタ命名規則に従っていないから。

以下、解説

frigga

friggaはNetflixから公開されているOSSです。

github.com

Utilities for working with Asgard named objects

friggaはAsgardで扱うオブジェクトの名前管理(バリデーションなど)をするライブラリらしいです。

AsgardはSpinnakerの前身であり、AWSのアプリケーションデプロイと管理をするWebコンソールでしたが、今はマルチクラウドでCI/CDを実現するSpinnakerに移行したようです。

github.com

Spinnakerでクラスタをデプロイしたことがある人はわかるかもしれませんが、SpinnakerではApplicaation Name, Stack, Detailで appName-stack-detail という名前をつけて各クラスタを把握していますが、以下のコードを見ると実はこれをfriggaが生成/管理していることがわかります。

Chaos Monkey

Chaos MonkeyもNetflixから公開されているOSSです。

Chaos MonkeyはNetflixがChaos Engineeringを行うためのツールとして代表的なものです。

ここでポイントなのはChaos MonkeyはNetflixが開発しており、Chaos Monkeyにおいてもfriggaがライブラリとして使われているということです。

そしてChaos Monkey v2と呼ばれるバージョンからはChaos Monkeyの動作はSpinnakerと連携するようになっています。 Chaos MonkeyはSpinnakerからクラスタインスタンスの名前を取得した上で対象となるインスタンスやPodを落とすようになっています。

Spinnaker

次にSpinnakerですが、上記でも述べたようにSpinnakerはAsgardの後継としてAWSだけではなくマルチクラウドでCI/CDを実現するOSSです。

www.spinnaker.io

対象とするクラウドAWSGCPなど以外にもOpenStackやKubernetesなども含まれており、こうしたクラウド環境に対してChaos Monkeyと連携しChaos Engineeringを実現することが可能となっています。

・・・というのがREADMEなどに書かれている内容なんですが、実はKubernetes provider v2においてdeploymentなどを使うとChaos Monkeyが動きません。

原因は以下のSpinnakerドキュメントに書いてあるとおりです。

Kubernetes Provider V2 (Manifest Based) - Spinnaker

You can deploy existing manifests without rewriting them to adhere to Frigga. Resource relationships (for example between applications and clusters) are managed using Kubernetes annotations, and Spinnaker manages these using its Moniker library.

ApplicationやClusterをKubernetesアノテーションやSpinnakerのMonikerというライブラリで管理するので、friggaに準拠しなくても良いようにしたとのことですが、これが原因でKubernetes provider v2においてはChaos Monkeyがfriggaの命名規則に合致しない deployment appName-stack-detail などという名前が出来上がった結果、friggaが管理する命名規則と合致せずエラーを起こしChaos Monkeyが動かないケースが有るという状態になっております。

一応こちらのIssueに上がっており、Slackでもお話はしてコミュニティには伝えたもののまだ対応はされてない模様。

github.com

Serge Poueme [3 months ago] Hi @mahito seems to be that yes. I just had a call with Ben, Ethan and Isaac ( Spinnaker office hours ) and they mentioned the mismatch between the v2 provider responses and chaosmonkey. A workaround would be to use replicasets instead of deployments. I will see if I can try that on our current dev project with minimal impact on the overall service definition.

今の所Chaos Monkeyの対象を Deployment にすると動かないので ReplicaSetを使うのが回避策らしい。

リュック選び

そろそろ今使っているリュックがダメになってきたので新しいリュックを探している。

仲間内のSlackで聞いてみると以下の6つが候補に。

[ドイター] deuter グラント D80604 7000 (ブラック)

[ドイター] deuter グラント D80604 7000 (ブラック)

[ミレスト] バックパック LAGOPUS PC収納可 MLS238-NV ネイビー

[ミレスト] バックパック LAGOPUS PC収納可 MLS238-NV ネイビー

GW明けをめどにポチる予定。

v2 Managed Pipeline Template

Spinnaker v1.12.0 からManaged Pipeline Template v2 というのがでてきたらしい。

www.spinnaker.io

This release adds alpha API and spin CLI support for MPT v2. See the blog post for more information.

詳しくは以下のBlogを見ろということらしい。

blog.spinnaker.io

ブログを読んでみると多分こういうことらしい(英語力不足)

MPT v2でできること

  • テンプレートの作成と編集の改善としてSpinnakerから取得したPipelineのJSONをそのままテンプレートの定義として使える。
  • spinからの MPT v2利用
  • テンプレートの標準化としてSpring Expression Language(SpEL)を、パイプラインとテンプレート用の単一の共有式言語として利用。
  • テンプレートの多重継承のサポートを辞めることで、サーバーサイドのMPTバックエンドを簡素化

今後何ができるか

  • v2 Pipeline Templateに対してFiatによる権限管理によりSpinnakerの管理者はどのユーザがPipeline Templateの作成、編集、読み込みコントロールできるように。
  • Sponnetライブラリが複数ソース、サポートされているモジュール、継承などから構成されるpipeline templateの構成をサポートすることで、MPT v1の頃よりMPTのバックエンドが大幅に簡素化される。
  • UIサポートの改善し、指定されたパイプラインのインスタンスがどのテンプレートを元にしたのか、どの変数値を指定されたのかなどを可視化が簡単に。

その他

sponnet library の変更の方を見てみたが、以前より大きい違いはmetadataとvariablesで、特に前者のmetadataのなかでscopeが設定できるようなので、ここがFiatと連携をして権限管理をしてくれるのかなと思う。

github.com

Amazon Prime会員の値上げにも気にならないお得なAmazon Mastercardゴールドの作り方

最近 Amazon Primeが年会費を1000円あげるというのが話題になったが、私もAmazon Prime会員なので以下のお便りが来た。

Amazon プライム会員の皆様

平素よりAmazonプライムをご利用いただきありがとうございます。Amazonプライムの会費変更に関するお知らせです。

Amazonプライムは2007年に配送特典のみで開始し、以降11年間、同価格でより多くの特典を追加してまいりました。配送特典対象商品は現在では数百万点に増え、プライム会員はその対象商品の配送を追加料金なしで無制限にお使いいただけます。さらに、Prime Videoの会員特典対象コンテンツへのアクセスや、Prime Music、Prime Reading、プライム・ワードローブ、世界各国で同時開催されているプライムデーなど増え続ける多様な特典の多くをご利用いただけます。プライム会員の皆様の生活を便利で豊かにするため、努めてまいります。

この度2019年4月12日付でAmazonプライムの年会費を3,900円(税込)から4,900円(税込)に変更する事となりました。

お客様がご登録されている年会費のお支払いプランにて会員登録の更新をされる場合は、2019年5月17日以降の会員登録更新時に新しい会費への変更が適用されます。

プライム会費の変更に伴う追加の手続きは必要ありません。会員登録は「アカウントサービス」でいつでも変更いただけます。

引き続きAmazonプライムをお楽しみください。

Amazon プライム

値上げがあるけどまだやめるような値段でもないので継続はしようと思っていたのだが、ちょうどクレジットカードを今の手持ちから変えようと思っていたところのAmazonプライム会員の値上げである。いろいろ調べているとどうも Amazon Mastercardゴールドがお得そうだということがわかった。

Amazon Mastercardゴールドは年会費10,800円が毎年必要なものの、プライム会員の会費が不要らしくこれだけで4,900円が浮く。 また2年目以降は年会費が最大6,480円割引のため実質無料でAmazonゴールドカードが持てることになる。

ご利用状況により、2年目以降から年会費が最大6,480円割引(税込み)割引 ・「マイ・ペイすリボ」でおトク ゴールドカードの方で「マイ・ペイすリボ」にご登録の方は、年に1回以上カードをご利用になれば、2年目以降から年会費が半額の「5,400円(税込み)」割引となります。

・「WEB明細書サービス」でおトク さらに「カードご利用代金WEB明細書サービス」のご利用で2年目以降年会費が「1,080円(税込み)」割引となります。 よって、最大税込み6,480円の割引となりますので是非ご利用ください。

よし、ではAmazon Mastercardゴールドを申し込もうと思ったところ、 どうも以下のようにAmazon Mastercardクラシックから申し込んだほうが良いとわかったのでまとめておく。

クラシック ⇒ ゴールド 最適オペレーション

クラシック ⇒ ゴールド 最適オペレーション

上記のユーザコメントでは以下のような手順が最適だと言っている

  1. Amazonにログインする
  2. AmazonMasterCardのリンクからAmazon Mastercardクラシックを選択する
  3. 5000ポイント獲得の文言があるのを確認したうえで申し込みをする(※Myペイすリボを申し込む(重要))
  4. クラシックカードが届くまで首を長くしてまつ
  5. 届いたらまずvPassを登録する
  6. そのままWeb明細を申込する
  7. Myペイすリボの月の支払額をカードの限度額に設定する
  8. Amazon Mastercardゴールドへの切り替えを申し込む
  9. ゴールドカードが届くまで首を長くしてまつ
  10. ゴールドカードが届いたらまずvPassに追加する
  11. Myペイすリボの月の支払額をゴールドカードの限度額に設定する
  12. Amazonアカウントの支払用クレジットカードにゴールドカードを登録
  13. Amazonの支払用カードからテンポラリーカードとクラシックカードを削除する

いきなりゴールドカードに申し込むとAmazonポイント5000ポイントが貰えないらしく、 クラシックカードを申し込み5000ポイントを得てからゴールドカードにしたほうがお得という流れらしい。

しかし、知人の情報によると7月のプライムデーは毎年ゴールドガード申込でキャッシュバックのキャンペーンがあるらしく、

「8. Amazon Mastercardゴールドへの切り替えを申し込む」の部分を

8. 7月のプライムデー Amazon Mastercardゴールドへの切り替えを申し込む」

とすることでよりお得にAmazonゴールドカードを手に入れられるらしい。

そんなわけで早速Amazon Mastercardクラシックを申し込んだので受け取り待ちのため、 次は7月のプライムデーを逃さず切り替えをしていく予定。