AWSでのマルチアカウントを攻略する

※書きかけの記事でしたが、完全に仕上げきる前に、ControlTowerが東京リージョンでローンチされたのでニーズは無くなったかも知れません。。。※

AWSを使い込んでいくと、開発案件ごとや環境ごと、技術検証や学習用のラボ環境など、複数のアカウントを使いわけたくなります。というか、分けることが推奨されています。 そんなマルチアカウント環境を構築するにあたり、いろいろ情報が散らばって存在しているので、整理しておくことにしました。

とても参考にさせて頂いたサイト

15分で教えるAWSの複数アカウント管理 - Qiita

Organizationsでイチから頑張るか、ControlTowerを使うか

マルチアカウント環境構築にあたり、ControlTowerの採用を考えた。マルチアカウント環境に必要な一式やセキュリティ対策のサービスとルール含めて一括構築してくれて、マルチアカウントの全リージョンを統合してダッシュボード化までできる。 本当はスゴくスゴく使いたかったのですが、東京リージョンが未対応だったので採用を見送り、自力で頑張ることにしました。

※ 2020.06追記 ControlTowerが既存のOrganizationsに対してあとから有効にできるようになりました。あとは東京リージョンに対応されれば移行しようと考えています。

※2021.04 さらに追記 しばらく仕事上でAWSから離れていたのですが、気付いたらControlTowerが東京リージョンで利用可能になっていました！→ https://aws.amazon.com/jp/blogs/news/aws-control-tower-tokyo/ すなおにこちらを利用するのが楽で良いと思います。

ControlTowerの対応リージョンとは何か

東京リージョン未対応って、結局何が出来て何が出来ないのかよく分からなかったので、実際にアカウント作って確かめました。

ControlTowerを使う場合、ControlTower自体が使ういくつかのサービスや監査ログのS3をどのリージョンに構築するか、という意味でリージョンを決める必要があります。 ここで、東京リージョンは選べないという事になります。 まあこれだけならControlTowerをバージニアとかで立ち上げて使えばいいか、と考えていました。しかし、大事なのは次。 ControlTowerを開始すると、AWS Configの必須ルールなどが適用されるのですが、これが東京リージョン含む"未対応リージョン"には展開されません。 これはツラい。というか使う意味が無くなった。 というわけでチマチマと自分で構築することにしました。修羅の道です。

このへん、AWSさんにはもっと頑張って欲しい。正直、プロダクト単位で環境を分離したいときにわざわざマルチアカウントにしないといけないのが、そもそもいけてない。ここだけはAzureのほうが使いやすい。確かGCPも一つのアカウントで複数の独立したクラウド管理できるし。AWSさん、なんとかなりませんか。頼みます。

アカウント統制やセキュリティ対策観点で使いたいサービス

• Organizations
• GuardDuty
• ConfigとConfig Aggregator
• CloudTrail
• SSO
• Securityhub

サービスの統合度合い

これがまた統一されていなくて、ややこしい。 基本的にそれぞれのサービスは、アカウント単位かつリージョン単位での管理がまずベースにある。 そして、サービスによって、マスターアカウントとメンバーアカウントの関係を構築して集中管理できるものや、Organizationsの組織に対して一元管理できるものなどがある。せっかくOrganizationsあるんだから、OU単位で扱えるように統一して欲しいです。

Security Hubでできること

• Amazon GuardDuty、Amazon Inspector、Amazon Macie AWS Identity and Access Management (IAM) Access Analyzer、AWS Firewall Managerなどのアラートや検出結果を一元管理できる
• マスターアカウントとメンバーアカウントによる集約
• Security Hubを使うには、そのアカウントでAWS Configが有効になっている必要がある。

Organizationsで使えるサービス

• CloudTrail
  • マスターアカウントで組織のすべてのアカウントのログを記録できる
• Config
  • アグリゲーターを使うことで組織全体のConfigデータを統合して可視化できる
  • アグリゲーターにより、単一アカウントの複数リージョンのデータを集約することも出来る
  • マルチアカウントに対してルールを集中的にプロビジョニングすることはできない。Configデータの収集のみ。ルールは個別にプロビジョニングする。
  • ルールの適合結果をメールなどで通知をしたいときは、ConfigからSNSトピックに投稿することができる。ただし、全部のタイミングで通知が発生するので、OKかNGかの判定結果に変化があったときだけ通知するようなニーズであれば、CloudWatch Eventsを使い、そこからSNSトピックに投稿するほうが便利。

※GuardDutyもOrganizationsでの一元管理に対応されました。 Amazon GuardDuty が、AWS Organizations のサポートでマルチアカウントの脅威検出を簡素化

最後に

まだまだ書き足りないのですが、いったんここまで。

プレゼンテーションのコツ

エヴァンジェリスト養成講座をあらためて読み直す機会があったので、まとめておくことにした。

新エバンジェリスト養成講座

この本は、セミナーのセットで購入したのだが、セミナー自体が激オススメです。

プレゼンテーションとは

• プレゼンのゴールは相手を動かすこと。話すことでも伝えることでもない。
• 相手を動かすことをゴールにおくと、資料のレビュー観点も変わる。
• 動かす例
  • 無関心を関心ありにする
  • 協力者になってもらい、自分の支援をしてくれるようになってもらう
• プレゼンテーションでは仕様より体験、価値を伝える
• 伝えたいことは何か？をブレークダウンして考える。要言語化。「新商品について伝えたい」はボンヤリしている。

視線誘導について

• 言葉で視線誘導する。そうできるようにスライドを作っておく。
• 視線誘導がとても大事。聞いていることと見ているものがズレていると入ってこない。

シナリオを作る

• 3:7の時間配分。本題7割、その前に課題提起とその回答に3割時間を充てる
• 相手にどういう行動を期待するかを決め、プレゼン中に語りかける、タイトルやサブタイトルに入れる
• ポイント
  1. なぜこの話をしなければならないのか？
  2. なぜ私はここにいるのか？
  3. なぜみなさんはここにいるのか？

デマンドを植えつける

• ほしい！やりたい！使いたい!と思う気持ちを植え付けること
• ないとどうなるか？どう困るか？を訴えるホラーストーリーが良い

スライド作成のヒント

• タイトルスライドは長く表示されるのでかっこよくする
• 1枚の中に同じワードが繰り返されないよう重複排除する

話し方

• 相手を見てしゃべることが難しい場合、それでは、続いて、そして、実は、なぜなら、といった接続詞のタイミングで相手を見るだけで、顔を見ているという印象になる
• カウントするときや、順序を説明するときは指を使う
• 最後のことばはあらかじめ準備しておくと良い
• 話し始めのことばも考えておくとよい
• 最初に、終了時間を告げること。相手が集中しやすい
• スライドにはファクトを書き、プレゼンでオピニオンを添えて読む。「5%というわずかな確率なので気にしなくてもよいでしょう」
• 絶対時間と相対時間を合わせてしゃべる。3年前の2017年の頃、、。相対時間は身近に感じて行動を促しやすい。
• 体言止め、質問と回答、魅力の語尾、を使ってプレゼンを単調ではなく魅力的にする
• 最初のうちに、うんうんとうなずいて聞いてくれる人を見つけ、ペースメーカーにする。

平成から令和になり、うどんからドライヤーにクラスチェンジした話

うどんとの出会い

AirPods Pro買ったのでレビュー

Apple AirPods Pro

うどんうどんとAirPodsを半ば馬鹿にしていた私ですが、通勤中の英語の勉強や音楽を聴くのに買ってみて、ワイヤレスイヤホンのあまりの便利さにしてやられたと感じました。スマホと耳をつなぐケーブルが実はいかに邪魔で、ユーザー体験を損ねていたのかを思い知ったしだいです。

そんな私が、ノイズキャンセル機能付きのAirPods Proを購入し、ようやく手元に届きましたのでレビューしたいと思います。

令和になりうどんもバージョンアップ

届きました、AirPods Pro! 実は注文したのは昨年の12/16日のこと。最初は11/13日にAmazonでオーダーしたのですが、まてど暮らせど入荷予定のめどが立たず、痺れを切らして公式から注文し直し、Amazonはキャンセルしました。 ですので、欲しい！買うぞ！と決めてから2か月ほど待たされたわけです。

箱はこんな感じですね。 まあいつものアップル製品らしい佇まいです。 というわけでさっそく開封します。 毎回思うのですが、フィルム包装されていますが、はがし始めるところが用意されていて、こんな感じにとても開けやすい。 この気配りが、地味に嬉しいです。最近子どもにDVD（Blu-rayではなく、、）を買ったのですが、フィルムピッチピッチ包装で、開け口もなく爪でカリカリやってフィルムをワイルドにひき裂いて開封するハメになるのですが、実にストレスフルなユーザー体験ですよね。みなさん見習って欲しいのですが、特許でも取っているのか、他社プロダクトであまり見ないんですよね。コストの問題かなぁ。

箱を開けたところです。シンプル。 取り出したところ。 先代より横長のケースの中に、ドライヤーが入っています。慣れるまで、ケースから取り出すのが難しかった。指でつまもうとするのではなく人差し指の腹で押し出すようにしてやると取り出しやすいです。 本当にドライヤーみたいですね。

軸に少し平らになった部分があるのが見えますでしょうか。ここをつまむとカチッとクリックできるようになっていて、再生を開始したり、曲送りしたりと、操作をすることが出来ます。長押しするとノイズキャンセルの有無を切り替えられます。従来のAirPodsではトントンっとタップする操作系でしたが、Proではカチッと感があるので、より分かりやすいように思います。本当にクリックできているのか、ハプティックでそう感じるような仕組みなのかは分かりませんが、Goodですよ。

ファーストインプレッション

とりあえず使ってみました。たまたま洗濯機を回しながらだったのですが、耳に入れてしばらくすると少しトンネルに入ったときのような違和感があり、続けてシーンとがなりました。これには本当に驚き、一瞬何が起こったのわかりませんでした（大げさかもしれませんが、ノイズキャンセルイヤホンは初めてだったので本当に驚いた）。 試しにノイズキャンセルをOFFにしてみたところ、洗濯機はちゃんと回っていました。

これは通勤電車の中や、新幹線車内での使用に期待できそうです。来月は出張で新幹線に乗るので、忘れずに使いまくりたいと思います。

2020/01/14追記 通勤電車の中で使ってみました。高めの音はけっこう聞こえることが分かりました。例えば線路の継ぎ目のガタンという音。対して、ゴーという風切り音はほとんど聞こえなくなります。あえてそういう仕様になっているかも。もしくは、AirPods Proのノイキャンの仕組みは知りませんが、瞬間的に発生する音はキャンセルが難しいのかも知れませんね。

Gitこんなときどうする（GitLab）

社内でGitLabを使い始めました。個人レベルでPC間のファイル同期用途としては以前から使用していたのですが、実務かつ複数人で使い出すと操作に困ることが多かったので、『このときはこう！』というのを書き残していきたいと思います。

そもそものブランチの使い方

これには正解はないが、今のところGitLabFlowをベースにしてこんな感じのルールにしています。

リモートリポジトリにはmasterとstagingとproductionを用意。masterは最初からずっと、stagingとproductionは初回リリース以降はずっと存在し続ける。作業は、masterから要件単位にfeature/xxxブランチを切って行う。

ローカルの作業はfeatureブランチで行い、コミットは各自のタイミングで。単体テスト終わるまではそのまま。テスト完了したものをpushし、masterブランチにマージリクエストする。

ある程度の区切りで、masterブランチをstagingブランチにマージして、ステージング環境での動作確認や顧客デモを行う。

実際のリリースタイミングでproductionにマージしてバージョンタグ(v1.1.0など)を付けています。

このときはこう

ローカルリポジトリで細かくコミットしているが、細かすぎるのでまとめたい

ローカルリポジトリのコミットは個人の自由なタイミングで行っています。ですが、1つのfeatureの実装が終わり、ソースレビューに出すときなどに、細かなコミット多いとログインが汚れるし、レビューする側も見づらいです。

そんなときは、複数のコミットをrebase -i でまとめます。

$ git rebase -i

出力イメージ

pick 9dfab7ac 〇〇機能追加しました

pick c04aced8 レイアウト調整

pick ee35f7dc テストコード追加

エディターが開き、コミットが古いものから順にリスト表示されるので、pickをsに変更する。

ブランチ切って開発中に、リリース済みのバージョンに緊急対応が発生したとき

作業中ブランチでは緊急対応しないこと。masterからhotfixブランチを切って、対応してmasterにマージする。masterには、前回のリリース以降に開発した、未リリースのfeatureがマージされている可能性があるので、hotfixのマージコミットだけをcherry-pickして適用する。

作業中のブランチに、他の人のコミットを取り込みたいとき 

他の人のコミットをすべて取り込んで、最新のベースに合わせるときは、rebaseをする。

hotfixブランチで対応したものだけを、開発中のブランチに取り込むには、cherry-pickを行う

戻したい系

コミットを取り消す

コミットを取り消すには、reset(リセット)を使う

• コミット操作を取り消す(変更内容を未コミットに戻す)

$ git reset --soft HEAD^

• コミット内容ごと取り消す(変更内容も無くなる)

$ git reset --hard HEAD^

取り消したことを取り消す（直前のリセット操作を取り消す）

$ git reset --hard ORIG_HEAD

プッシュを取り消す

$ git revert 

$ git push

マージを取り消す

• マージしようとしたらコンフリクトして編集もしたけど諦めてやっぱりやめたいとき

$ git reset --hard HEAD

• マージ完了、未プッシュのとき

$ git reset --hard ORIG_HEAD

• マージ完了、プッシュもして共有済みのとき

$ git revert -m 1 <マージコミットのID>

 GitKraken

Git操作にGUIツールとしてGitKrakenを使っているので、そちらについてもメモ。

リベース操作

GitKrakenでリベース操作をする際に、いつもいつも操作を間違えるのでメモを残しておきます。

dev, topicの2つのブランチがあって、topicブランチで開発中にdevがけっこう伸びてきたのでリベースしたい。topicはまだ開発中なので、マージするのではなく、最新のdevを取り込んでおきたい。

操作

1. topic/XXXブランチをチェックアウトする
2. devブランチ上で右クリックし、"Rebase topic/XXX onto dev" を実行する
3. コンフリクトなどに適宜対応し、完了する

 まだまだカバーしきれていない「こんなときどうするっけ？」がありますので今後も更新していく予定。

プッシュする前にコミットをひとつにまとめたい

こちらもリベースを使います。

ローカル作業中に、ちょっと大きなリファクタリング着手する前とかで自由にコミットできるのがGitのいいところです。しかしながら、そのままプッシュすると、『リファクタリング前にいったんコミット』『テストコード修正』『修正コメントを追記』みたいに、ちょっと散らかったコミットログになってしまいます。

リベースを使うことで、プッシュする前に複数のコミットをひとつのコミットにまとめてからリモートに反映することができます。

操作

1. まとめたいコミットたちの先頭のコミットのひとつ前のコミットを右クリックする
2. interactive rebase ... を選択
3. 対話リベース画面が開くので、上から全てsquashに変更する。一番下のみrewordにする
4. 実行する

SwitchBotで物理スイッチをIoT化

手軽におうちハック

2020/12/07 設置写真を追加しました

スマートホームだ、コネクテッドだ、とは言うものの、ネットワーク非対応な（コネクテッドでない）機器を全て入れ替えるのはハードルが高いですよね。

そんなとき使えそうなのが、以前紹介したNature RemoのようなWiFi経由でコントロールできる赤外線リモコンです。赤外線リモコンで操作可能な機器はこいつでなんとかなります。

それでもまだ、物理スイッチの操作が必要な機器はお手上げでした。

ですが、クラウドファンディングのIndiegogoでそんなお悩みを解決してくれそうなプロダクトを発見したので、さっそく入手してみました。

Switch Botという、物理スイッチを押してくれるガジェットです。

※この記事を書いたのは2年ほど前で、今ではAmazonで普通に買えるようです。

SwitchBot - Your simple switch to a smart home | Indiegogo

小さい箱がswitch botで、大きい箱にはスイッチリンクというハブが入っています。

switch bot はスマホアプリからBluetooth経由で操作しますので、単体ではリモート操作ができません。リモート操作を可能にするには、オプションのハブが必要です。ハブを設置すると、アプリからリモート操作できますし、IFTTT連携なども行えるようになります。

使ってみて

長年、買うだけ買って使い道を見つけられずにいたのですが（じゃあなぜ買ったというツッコミは無しで）我が家では、今では白と黒の2つのswitch bot君が活躍しております。

一つ目は、玄関灯のONOFF。夜になると点灯して、朝に消灯するようにタイマー設定しています。旅行や外出時の治安の面と、夜に仕事から帰ってきたとき、自転車のカギや家のカギが見やすいので、ここに使うことに決めました。

もう一つは、お風呂のお湯張りボタンを押す用途。事前にお風呂のセンをしておく必要はありますが、外出していて思いのほか帰りが遅くなったときなどに、帰ってすぐに子供をお風呂に入れることが出来るようになりました。このありがたさ、子育て世帯なら分かっていただけるのでは無いでしょうか。

お風呂のほうかはなかなか設置が難しく試行錯誤しました。お湯はりスイッチの左右は別のスイッチがあるのでダメ。上は液晶が見えなくなるのでダメ。となると残るは下側しか無いのですが、ここは開閉するフタになっているので、単に貼り付けるとスイッチオンのタイミングでフタがパカっとあいてしまい、スイッチを押し込むことができませんでした。そこで、子どものレゴブロックで土台を製作してなんとかなりました。

設置の仕方に工夫が必要な場合もありますが、ハマればとても便利ですよ。

Terraformコマンド備忘録

AWS環境のIaCのために、terraformを初めて導入してみたので、コマンドなどを忘れないようにメモ。ちなみに、CloudFormationとどちらを今後使い込んでいくか迷っているのですが、CloudFormationは数年間に少し触ってすごく面倒だった(当時)ので、遠ざかっていましたが、あれからだいぶたってYAMLにも対応したので使いやすくなっているかも、、。

基本のセット

terraform init
terraform plan
terraform apply
terraform destroy

initは本当の最初に一度だけ実行すると思っていたのだが、新たなproviderを使う構成にしたときなど、ときどき必要になる。

planで現在の状態とtfファイルとを比較して、実行計画を立てる。どこに差分があって、追加するのか変更で良いのか、削除するのか、といったことが計画される。 applyでも内部的にはplan相当のことをやったのちに、本当に実行するかを確認してくれるので、plan→applyの流れが必須というわけではない。 destroyで環境を削除する。

-targetオプションを使用することで、特定のリソースだけを構築したり削除することができる。 terraform destroy -target=aws_instance.web

terraform fmt # tfファイルのフォーマット整形
terraform console

terraform graph | dot -Tsvg > graph.svg
# 依存関係の可視化

便利関数

サブネットのCIDR

cidrsubnet("10.0.0.0/16", 8, 0)
# → 10.0.0.0/24

cidrsubnet("10.0.0.0/16", 8, 1)
# → 10.0.1.0/24

cidrsubnet("10.0.0.0/16", 8, 100)
# → 10.0.100.0/24

ホストのIPアドレス(のCIDR表現)

cidrhost("10.0.100.0/24", 3)
# → 10.0.100.3/32

実際の使いどころとしては、CIDRをベタ書きしたくないときに便利。 VPCのCIDRを基準にして、サブネットCIDRとその中に配置するホストのIPアドレスを表現することが出来る。

# VPC CIDRが10.1.0.0./16とする
cidrsubnet(aws_vpc.vpc.cidr_block, 8, 1)
# →10.1.1.0/24
cidrhost(aws_subnet.public_subnet, 25)
# →10.1.1.25/32

VPCのCIDRを変更したときにサブネットやホストのCIDRを書き換えなくても良いので、IaCが捗ります。

既存の構成のterraformへの取り込み

terraform import

しかし、importコマンドを使うやり方は、手順が多くて、やや面倒くさい。 そこで、terraformingがおすすめ。 全てのリソースには対応していないが、対応しているものはterraformingのほうが使いやすい

SVN信者をGitに改宗させる話

はじめに

最近、社内のバージョン管理ツールを（ようやく）SVNからGitに切り替えたのでその話。

新しいモノに触れようとしない、古い技術にしがみつく層が多く、そんなメンバーに改宗してGitを採用してもらうべくエヴァンジェリストな活動をしました。

やったこと

1. 座学による概念理解
2. ハンズオンによる体験と、Gitクライアント環境の個人PCへの導入
3. アフターフォロー

座学による概念理解

私自身が初めてGitを使い出したときに、SVNとは概念や用語の違いがあって、スッキリ理解するまでに時間がかかったので、メンバーにはそこを一気に飛び越えてもらえるように講義形式でレクチャーしました。 また、今のSVNから移行するにはスイッチングコストがかかるし、Gitは学習コストもそこそこ高いので、慎重派を動かすためには、SVNでのお困りごとがGitなら解決できますよ、という例示が効果的でした。

Gitのメリット

個人単位で任意にローカルコミットできる。

SVNだと、コミットしたコードは全体で共有されるので、ビルドが通らない、開発途中などの中途半端なものをコミットすると、他のメンバーの作業にも影響を与えてしまう。 Gitは個人単位でローカルリポジトリを持っており、そこに対してコミットしていき、ある程度まとめて共有リポジトリ（リモート）に対してプッシュという操作で反映する。 なので、「ライブラリを試してみてダメだったら戻す」とか、「リファクタリング前にいったんコミット」なんかが圧倒的にやりやすい。

（GitLab）コードレビューのための仕組みがある。

マージリクエストという仕組みを使うことで、ソースコードレビューをブラウザ上でできて、指摘コメントなどの記録も残せる。これまではレビュー記録票というExcelシートを使っていました。 マージのコンフリクト時も、ブラウザ上でコンフリクト解消してマージ作業を完結することができる。

並行開発がやりやすい

段階リリースだったり、アジャイルとかイテレーティブな開発スタイルを採用している場合に相性がよい。どのようなブランチモデルで運用するかにも寄りますが、本番稼動しているバージョンのコードには手を付けずに、開発ブランチであれやこれや機能追加して、テストして、ということができる。これの何が便利かというと、開発途中に本番系で緊急対応が必要になったとき、緊急対応部分だけをリリースすることが出来る。ほかにも、並行開発ありきで作られているので、便利なコマンドがたくさんある。

ハンズオン

座学だけでは、いざ使おうというときに、環境構築やらなんやらで結局つまづいたり時間が取られてしまうので、ハンズオン形式で環境構築とGit操作体験まで一気に立ち上げることにしました。 これにより、自分のPCにGitクライアント環境が整うので、いつでも使い始められる状態になり、使い始めるときのハードルを下げることができると思います。

アフターフォロー

困ったときにいつでも気軽に質問してくれていいですよ、というアナウンスと、そのためのチャネル（Slackなど）を用意しました。 さらに、初めて導入するというプロジェクトでは、近くに座るなどして、何か困ったときにすぐフォローしてあげられるようにするのが良いですね。現場コーチっていうんですかね。

最後に

技術のアンテナ張っている人たちは、布教活動はしなくても、ハンズオンだけでも効果ありと思います。しかし、慎重派、現状維持派の人をスイッチさせる（説得する）には、彼らが理解できるレベルで何かしらのメリットを提示する必要があります。 これって、実は普段の仕事でも必要なスキルだと思います。 技術者の興味だけではなかなか新しい技術の採用は難しく、その技術によって何を変えることができるのか、を説明できることって大事だと思います。