AWS認定ソリューションアーキテクト アソシエイト(AWS SAA-C03)に合格しての感想(C01からの再認定編)


これまで、AWS認定ソリューションアーキテクト プロフェッショナル(AWS SAP-C01)AWS認定DevOpsエンジニア プロフェッショナル(AWS DOP-C01)に合格してきたので、本来は再認定の日までにこの2つの試験を再受験すればいいのですが、AWS認定ソリューションアーキテクト アソシエイトのバージョンがC03まで上がっているということや、ここ最近サーバレスやコンテナのようなモダンアプリケーションを構築するお仕事に関わることが多くなってきたので、それらの経験で得た知識がどこまで付いているのかを効果測定するためにも、受けてみることにしました。

結果は777点で合格。上位資格に受かっていることを考えると、本当は800点以上のスコアを叩き出したかったのですが、出題範囲や分野が前回受けた内容と異なることを考えると、これはこれで納得のいくスコアなのかなぁと思います。

ついでに再認定扱いになったので2024年7月までだった再認定までの猶予期間も2026年2月まで延長させることができました。まずは一安心です。

どのようにして勉強したのか

今回この試験を受けるにあたって何をどのようにして勉強したのかというと、実はほとんど試験対策のような勉強の仕方はしてきませんでした。なぜかというと、前述の通り、前回の受験からの実務経験が本当に身についているかどうかの効果測定が目的だったからです。この試験を受けること自体が完全に手段化していました。なので試験ガイドの内容を確認した程度で、他に試験勉強をしたというのがなかったのです。これまでの経験と知識全てで勝負したという感じで。

強いて勉強らしいことをしたとすれば、「AWSで実現するモダンアプリケーション入門(落水恭介 吉田慶章著/技術評論社)」を3周くらい読みました。この本はAWSが提唱するモダンアプリケーションという考え方に沿って、既存のモノリシックなAWSの構成をいかにして改善させることができるかという考え方について、事例を交えながらわかりやすく書いてくれている良書だと思いますし、試験で出題される分野にかなり近いところを題材として採用しています。自分にとってはこれで十分だったかなと思っています。

ここでは具体的にどのような問題が出たのかについては、行動規範に抵触する可能性があるので言及はしません。ただ強いていうのであれば、だいぶ出題範囲が広くなっているのと同時に、モダンな方向にシフトしているなぁ、という感想は持ちました。

現時点で市販されているAWS SAA向けの試験参考書でC03のバージョンに対応しているのはごく僅かなので、初めてAWS SAAを受ける人にとっては結構大変かもしれませんが、座学だけではなく、実際にハンズオンをして試してみた方が理解は早いかもしれません。実務と紐づいてこその資格なので、手を動かしてみるほうが周り道に見えて実は近道なんじゃないかなと思います。

アソシエイト試験はその内容から、プロフェッショナル試験とは違った難しさがあるのですが、それは相変わらずでしたね。特に初めて挑戦する人は、十分に準備期間を設けてチャレンジしてみるほうがいいのかなと思います。

カテゴリー: AWS | タグ: | コメントする

PritunlとAmazon DocumentDBを使用したVPNの仕組みを構築しようとして失敗した話


はじめに

社内のVPNの仕組みも社員数が増えてくるにつれてそれなりに管理がしやすいような方がいいよね、ということで、仕組み自体を更改するにあたり、VPNサーバを簡単に構築 & 管理することのできるPritunlと、ここが一番肝心なのですが、どうせならPritunlが使用するデータソースをAWS上で構築したいよねということで、Amazon DocumentDBを使用しようという話になり、ちょっとPoCをしてみましたというのがこの記事の趣旨になります。

まぁ最終的にはPritunlのデータソースとしてAmazon DocumentDBが使えない! という結論に至ったのですが、その理由は後述します。

構成

ざっくりと構成図書くとこんな感じになります。他にも社内のルータとかが登場するのですが、それは流石に出せないので、あくまでもVPNサーバとAmazon DocumentDBの関係性だけを記述しています。

Amazon DocumentDBの前段には、Public Subnetにルータとしての機能を持つEC2インスタンスを構築します。可用性はあまり求められないのでシングルAZ(AZ-a)にしていますが、Amazon DocumentDB側でサブネットグループの構築が必須となるため、AZ-cを空っぽの状態で構成しています。

VPS上に構築するVPNサーバは、今回はUbuntu 22.04 LTSを使用しています。

EC2インスタンスからAmazon DocumentDBへの接続確認

構築したEC2インスタンスにmongoDBをインストールして、内部的にAmazon DocumentDBへ接続が可能かどうかを確認します。当然のことながら、EC2インスタンスにはAmazon DocumentDBに対する接続を許可するIAMロールの設定をして、Amazon DocumentDBに対してはインバウンドでEC2インスタンスからのtcp/27017の通信を許可するSecurity Groupのインバウンドルールを設定しています。

まずはEC2インスタンスにmongoDBをインストール。

sudo echo -e "[mongodb-org-6.0] \nname=MongoDB Repository\nbaseurl=https://repo.mongodb.org/yum/amazon/2/mongodb-org/6.0/aarch64/\ngpgcheck=1 \nenabled=1 \ngpgkey=https://www.mongodb.org/static/pgp/server-6.0.asc" | sudo tee /etc/yum.repos.d/mongodb-org-6.0.repo
sudo yum install -y mongodb-org -y

これが完了したら、Amazon DocumentDBに接続するための証明書を取得してきます。

wget https://s3.amazonaws.com/rds-downloads/rds-combined-ca-bundle.pem

そして、以下のコマンドで接続確認を実行します。

sudo mongosh --tls --host <cluster name>.cluster-<cluster identifier>.ap-northeast-1.docdb.amazonaws.com:27017 --tlsCAFile rds-combined-ca-bundle.pem --username <username> --password <password>

実行後、以下のように出力されれば接続は成功です。

Current Mongosh Log ID: <Log ID>
Connecting to: mongosh://<credentials>@<cluster name>.cluster-<cluster identifier>.ap-northeast.docdb.amazonaws.com:27017/?directConnection=true&tls=true&tlsCAFile=rds-combined-ca-bundle.pem&appName=mongosh+1.6.2
Using MongoDB: 4.0.0
Using Mongosh: 1.6.2

(snip...)

rs0 [direct : primary] test>

VPNサーバの構築

AWS側の構築と設定が完了したら、次にVPS上のVPNサーバを構築していきます。

まずはAWS CLIのインストールから。

curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
unzip awscliv2.zip
sudo ./aws/install

次にPritunlをインストールしていきます。

# まずは既存でインストールされているパッケージを最新バージョンに更新
sudo apt update && sudo apt upgrade

# PritunlとMongoDBをインストール
sudo apt update && sudo apt install pritunl mongodb-org

# インストールしたPritunlとMongoDBを起動
sudo systemctl start pritunl mongod
sudo systemctl enable pritunl mongod

ここまで終われば、あとはPritunlとローカルのMongoDBの起動状態を確認すればOKです。

Pritunlの設定

Pritunlを初期セットアップするためには、セットアップキーの取得が必要なため、以下のコマンドを実行します。

sudo pritunl setup-key

実行すると16進数のセットアップキーが表示されるので、それを控えておきます。

次に、https://<VPNサーバのIP Address>/setup をブラウザで開き、表示されたダイアログにセットアップキーを入力します。

[Save]ボタンを入力すると、管理者のユーザ名とパスワードを作成しろというダイアログが表示されるので、コンソールに戻り、以下のコマンドを実行して管理者のユーザ名とパスワードを作成します。

sudo pritunl default-password

ここで出力されたユーザ名とパスワードを控えておきます。

もしもVPNサーバのローカルに構築されたMongoDBを使用してPritunlを使用する場合は、ここで構築は完了なのですが、ここで、一旦VPNサーバからDocumentDBに接続が可能かどうかを、EC2インスタンスから接続確認した時と同じ手順で接続を確認します。

sudo mongosh --tls --host <cluster name>.cluster-<cluster identifier>.ap-northeast-1.docdb.amazonaws.com:27017 --tlsCAFile rds-combined-ca-bundle.pem --username <username> --password <password> --tlsAllowInvalidHostnames

ここまでは普通に成功するはずです。

PritunlのデータソースとしてAmazon DocumentDBが使えないことが発覚

ここで、/etc/mongod.confのデータベース接続文字列を修正して、Amazon DocumentDBを向くように設定したのですが、ここでInternal Server Errorが発生。/var/log/pritunl.logに以下のような大量のエラーが吐かれます。

[undefined][2023-01-20 09:38:17,828][INFO] Starting setup server
[undefined][2023-01-20 09:38:18,153][INFO] Generating setup server ssl cert
[undefined][2023-01-20 09:38:22,654][ERROR] Pritunl setup failed
Traceback (most recent call last):
  File "/usr/lib/pritunl/lib/python3.10/site-packages/pritunl/setup/__init__.py", line 43, in setup_all
    setup_mongo()
  File "/usr/lib/pritunl/lib/python3.10/site-packages/pritunl/setup/mongo.py", line 446, in setup_mongo
    mongo.secondary_database.create_collection(
  File "/usr/lib/pritunl/lib/python3.10/site-packages/pymongo/database.py", line 425, in create_collection
    return Collection(self, name, True, codec_options,
  File "/usr/lib/pritunl/lib/python3.10/site-packages/pymongo/collection.py", line 187, in __init__
    self.__create(kwargs, collation, session)
  File "/usr/lib/pritunl/lib/python3.10/site-packages/pymongo/collection.py", line 264, in __create
    self._command(
  File "/usr/lib/pritunl/lib/python3.10/site-packages/pymongo/collection.py", line 238, in _command
    return sock_info.command(
  File "/usr/lib/pritunl/lib/python3.10/site-packages/pymongo/pool.py", line 710, in command
    return command(self, dbname, spec, secondary_ok,
  File "/usr/lib/pritunl/lib/python3.10/site-packages/pymongo/network.py", line 161, in command
    helpers._check_command_response(
  File "/usr/lib/pritunl/lib/python3.10/site-packages/pymongo/helpers.py", line 167, in _check_command_response
    raise OperationFailure(errmsg, code, response, max_wire_version)
pymongo.errors.OperationFailure: Feature not supported: capped:true, full error: {'ok': 0.0, 'code': 303, 'errmsg': 'Feature not sup
ported: capped:true', 'operationTime': Timestamp(1674175102, 1)}
[undefined][2023-01-20 09:38:22,658][INFO] Stopping server

該当するコードを調べてみたのですが、Pritunl側では、セットアップ時のmongoDBに対する設定として、上限付きコレクションが Trueになっているのですが、Amazon DocumentDBの仕様ではFalseになっており、変更不可であるため、セットアップそのものができない状態になってしまっているのでした。万事休す。

というわけで、PoCはここで泣く泣く終了になってしまいました。この辺のPoCに関してはなかなかまとまったドキュメントがないので、ここに至るまでに結構時間を溶かしてしまいました。Pritunl側のUpdateを待つか、Amazon DocumentDB側で上限付きコレクションの設定がサポートされるかどうか、今はちょっと待ちの状態ですね。

ただ、どちらかがサポートされれば、AWSのリソースで効率的にVPNサーバの管理ができるようになるかもしれません。

カテゴリー: AWS, Work | タグ: , , | コメントする

2022年のフライトログとBronzeステイタス継続


はじめに

去年からANA Bronzeのステイタスに到達したのですが、今年もそれを継続すべく、まぁ飛行機にはよく乗りました。多分年間7往復したのは初めてなんじゃないかなと思います。

というわけで簡単なフライトログをば。

フライトログ

  • 2022/1/15 NH245 HND → FUK (B788 / JA802A)
  • 2022/1/16 NH258 FUK → HND (B788 / JA831A)
  • 2022/2/25 NH243 HND → FUK (B788 / JA838A)
  • 2022/2/26 NH256 FUK → HND (B788 / JA831A)
  • 2022/6/17 NH019 HND → ITM (B788 / JA840A)
  • 2022/6/19 NH024 ITM → HND (B788 / JA815A)
  • 2022/7/9 NH677 HND → HIJ (A321 / JA139A)
  • 2022/7/9 NH684 HIJ → HND (A321 / JA151A)
  • 2022/10/17 NH055 HND → CTS (B763 / JA608A / 鬼滅弐号機)
  • 2022/10/19 NH070 CTS → HND (B788 / JA810A)
  • 2022/11/12 NH395 HND → SYO (B738 / JA63AN)
  • 2022/11/12 NH400 SYO → HND (B738 / JA72AN)
  • 2022/12/3 NH245 HND → FUK (B772 / JA745A / 鬼滅参号機)
  • 2022/12/4 NH252 FUK → HND (B788 / JA818A)

相変わらずB788には乗っていますね。もうすでにANAの主力機になっているので幹線に搭乗しようとすると大概にしてB788に当たりますが、好きな飛行機なので全然問題ありません。まさかのまさかだったのが、3機就航している「鬼滅の刃」コラボ機に期せずして2機登場してしまったこと。ラッキーと言えばラッキーなのかもしれませんが、あの機内アナウンスはちょっと恥ずかしいですね。でも個人的には楽しめたのでよしとします。

そういうわけで2年目のANA Bronzeステータスに突入

そんな感じで乗りまくったので、年末には今回もANA Bronzeのステータスを獲得することができました。2年目になるので来年はマイルの積算率が上がりますね。欲を言えばDiamondまでいきたいところですが、そこを目指そうとすると海外に行くことも視野にいればければいけないので、ご時世柄このままBronzeを継続していければいいのかなと思っています。あまり欲は出しません。

なんやかんや言っても飛行機の旅は大好きなので、来年も無理のない範囲で乗りまくる所存であります。

カテゴリー: Private | タグ: | コメントする

PSY・Sとわたし – “Wondering Up and Down”


きっかけ

PSY・Sの元ボーカルで、現在はジャズヴォーカリストとして活躍しているCHAKAさんのこんなツイートを読んだんですよね。

色々考えるきっかけになったCHAKAさんのツイート

もちろんファン的には一体どんな批評を読んだんだろう、というのが気になったりもしたのですが、その批評に左右されることなく、これからも高みを目指していこうとしている決意表明をしているCHAKAさんの力強い言葉に、すごいなと思ったのでした。PSY・Sは全盛期が自分の多感な高校生という時代と同期しているので、それだけに思い入れがあって、色々と考えてしまったわけです。

あれやこれや

PSY・Sというアーティスト名を聴いて、あ、あの人かとわかる人は、おそらく同世代ですね。1985年にデビューし、1996年に解散した、ヴォーカルのCHAKA(安則まみ)さんと楽曲全般の演奏を担当する松浦雅也さんからなるユニットです。

その当時最先端の技術を駆使をして、先進的かつポップな世界観を全面に出した楽曲をいくつも発表してくれて、そのオリジナリティにはワクワクしたものです。昔話ですけれどもね。もう解散して25年以上が経過しているのか。今でもかなりのヘビーローテーションで聴く続けているんですけれども。

PSY・Sを知ったきっかけは高校の先輩がカセットデッキで部活の時間に流していたのをきいたところからだと思います。オリジナリティあふれる楽曲と、なんといってもCHAKAさんのまっすぐなハイトーンボイスが突き刺さったんですよね。あの歌声はそんじょそこらじゃ忘れられません。

その頃の音楽シーン、正直ヒットチャートは全く追いかけていなかったですね。むしろ、多数創刊されていたFM雑誌からアーティスト情報を知ったり、いま(当時)渋谷系という音楽が一部で流行っていて、それを試しに聴いてみよう、という感じで、FM放送を媒介としてさまざまなジャンルの音楽に触れられる機会がいま以上に幅広かった気がします。

で、その中でなんでPSY・Sなのかって、一つ一つの楽曲が粒が際立っているというか、ポップなんだけれどもただのポップでは済まされない、良い意味での「変てこりんさ」があったところなんですよね。それでいて聴き飽きることが全くないんです。耳障りの良さだけではなくて、少し角が立っているところが。そこにCHAKAさんの力強い歌声が乗ってきて、不思議な化学反応が起きていたなと。CHAKAさんの歌声もまっすぐさが半端なくて、思わず聴き入ってしまう魅力があったのです。

解散の理由は正直覚えていないなぁ。ただかなりショックではありました。CHAKAさんの立場と松浦さんの立場、それぞれに何かしらの思うところがあったのではないかと思うんですが、あの二人だからこそできた音楽がそこにあって、新作の中でどんな世界観を披露してくれるかが本当に楽しみだったので。

一番好きな曲

これはこのBlogを吹っ飛ばす前の記事でも書いたのですが、“Wondering Up and Down 〜水のマージナル〜”が本当に好きで、今でもずっと繰り返し聴いています。自動的に自分の子供時代を思い起こさせてくれるような抒情的なメロディライン。ベースラインが同じなのにメロディとサビとで全く違う表情を見せてくれるところ。目を瞑ればその景色がすぐに想像できるような優しい歌詞。そしてその世界をクリアに歌ってくれるCHAKAさんの歌声。

歌詞は水にまつわる様々な情景をシーンごとに切り替えていく構成になっているんですけれども、それがメロディと組み合わさった時の化学反応が半端ないというか。具体的にこうとかまでは書けないのがなかなか悔しいんですけれども、こういう初夏の風景があると本当に素敵だよなということを思い起こさせてくれるような感じです。

またあれやこれや

サブスク時代が前世の今の時期、歌い出しのインパクトや貴キャスさがとにかく優先されるようになってきてしまったような気がしますが、PSY・Sの音楽の世界はその真逆をいくように、じっくり聞けば聴くほどその世界観がふわっと広がっていく印象を受けます。その広がりが本当に素晴らしいんですよね。それはCHAKAさんの歌声がどうだからとか、松浦さんの作曲が素晴らしいからとかではなくて、それらが融合しているからこその魅力なんだと思います。

多分、”Wondering Up and Down 〜水のマージナル〜”は、ずっとずっと聴き続けているんだろうなと思います。音楽が与えてくれる多幸感が得られる限りは。あの歌声になんと心を癒されたことか。

カテゴリー: Private | タグ: , | コメントする

コミュニケーションコストと手間暇について僕自身がいま考えていること


はじめに

この記事は #Backlog アドベントカレンダー2022 by #JBUG の12/18分の記事として執筆しています。

コミュニケーションコストとは?

現在勤めている会社は渋谷にオフィスがあり、この記事を書いている直近ではだいたい50%くらいの社員がリモートワークをしています。僕もそのうちのひとりで、オフィスに出社するのは1週間から2週間に1回くらい。その他は主に自宅で仕事をしています。コアタイム制ですが、多くの社員の勤務開始時間は割と遅めな感じな一方で、朝早めの時間から勤務を開始しているメンバーもいます。

そういう環境の中で、ほとんどオフィスに出社しているメンバーの人からちょくちょく「リモートワークだとコミュニケーションコストがかかるから」という言葉を耳にすることがあります。具体的な例としては、オフィスに出社していればちょっとした相談事でもその人の席まで行って話をすればすぐに解決できることが、リモートワークだとタイムラグややり取りに関する時間的なコストが発生して、解決に至るまでのスピードが遅くなる、といったところが代表的でしょうか。そこにコストがかかることに課題を感じているようです。

いや、仰っていることはよくわかるんですよ。確かにオフィスの中をとことこ歩いていって相談相手と対面で話すことの方が、時間的なロスは少ないし、相手の表情を見ながら話すことができるので、解決までの道のりは、もしかしたら早いかもしれません。

だがしかし待てよ、「コニュニケーションコスト」って果たしてそういうものなのかしら? というところに個人的には疑問を感じてしまいます。

コミュニケーションにかける手間暇についての僕の思うところ

上記に関する「コミュニケーションコスト」というのを時間的な価値だけにフォーカスするのであれば、確かにそれはスピード感を持って意思決定をする上ではみんなが同じ場にいて同期的に話を進めていけばいいかもしれません。その方が手間暇は全然かかりませんし。

ただ、「コミュニケーションコスト」は、逆に手間暇というか、ちょっとした工夫を使いながらかけるべきでもあると僕は思うのです。

ここでは例としてBacklogとSlackを挙げてみましょう。

Backlogを通じたコミュニケーションに対してかける手間暇

この記事を読んでいる皆さんの中には何かしらのチケット管理ツールを使用してプロジェクトを進めている方が比較的多いのではないかと思います。僕の会社でもBacklogを使ってプロジェクト管理を行なっています。なんですけれども、Backlogの機能を十分に使いこなせていないなと思ってしまう事例が少なくないのです。ひとつひとつの起票された課題(親課題や子課題を含めて)に対して、それがなんのために起票されているのかという意味合いを持たせていないケースが散見されるのです。結果としてどういうことが起こるかというと、後から見返したときに「このBacklogの課題って何のために起票されたんだっけ?」という「コミュニケーションコスト」が発生してしまうわけです。これはあまり建設的なコストではないですよね。

もちろん、Backlogにはこれが鉄板というルールブック的なものはないわけですけれども、起票された課題に対して意味合いを持たせ、その課題が結果としてとのような状態になったかを育てていった方が、ツールを使っていく上での価値がダントツに上がるわけです。少なくとも、課題の本文やコメントに、

  • なぜこの課題を起票したのか (= 課題が示している目的を明確にする)
  • どういう状況になっていればその課題はクローズできるのか (= 課題の完了条件を明確にする)
  • 課題のステータスを変える時には、その理由 (= 完了に向けて具体的にどのようなアクションをとっているのかを明確にする)

これらが書かれていれば、課題に対する活動の履歴がはっきり残るため、「この課題って何だっけ?」状態は確実にクリアできると思っています。逆に言えば、「コニュニケーションコスト」を軽減するための材料を、少し手間暇をかけることで用意することができるわけです。これは明らかに建設的な手間暇であると考えることができると思うのです。

Slackを通じたコニュニケーションに対してかける手間暇

同じように、日常の仕事の中での課題の共有や調整などを、Slackのようなチャットツールでやり取りしている例も多いのかなと思います。

SlackはBacklogのようなストック型のツールではなく、フロー型のツールとも言えます。フロー型である以上は、短いスレッドで完結させる方が良いに越したことはないのですが、必ずしもその通りにならないことが往々にしてあるのは皆さんもよく経験されているのではないかと思います。その原因として考えられるのが、やはり書き込まれている最低限の情報が網羅されているか、なのかなと考えています。網羅すべき情報は、Backlogの場合とほぼ同じで、

  • そのスレッドを通じて共有したいことや質問したいことは何か (= 目的を明確にする)
  • 情報共有の場合、伝えたい相手に対して何を理解してもらいたいか (= 完了条件を明確にする)
  • 質問の場合、結果としていつまでにどんな情報が欲しいのか (=完了条件を明確にする)

これらが書かれているだけでも、情報を伝えたい相手に対して余計な「コニュニケーションコスト」を発生させることなく、建設的に物事を進めたり、調整したりすることができるわけです。そのための手間暇としても建設的なのではないかなと思います。

時間的なコストを削減するためにも手間暇を少しかけよう

ここでは2つの例を書いてみましたが、「コミュニケーションコスト」というのは、単純に時間だけで評価できるものではなく、その人の持っている情報がどれだけ多くの人に対して正しく共有できるかというのも重要な評価軸なのではないかと思います。オフィスにいて、ちょっと誰かと相談すれば、2者間では情報の共有がすんなりいくかもしれませんが、そこで得られた情報を多くの人に共有できるかと言えば、実は共有できなかったりしますよね。その結果、「これって何だっけ?」「確かこういうことだった気がする」というようなやりとりに発展して逆に時間的なコストをかけてしまうことになることもあったりするわけで。

それを補完するのがプロジェクト管理ツールやコミュニケーションツールの役割であるわけで、そこに少しだけ手間暇をかけてあげることで、有益な情報共有の手段として育てていくことができるのだと思います。そして育てることによって、いつかプロジェクトや会社の事業にとっても大きな資産となり得ます。

非同期的なコミュニケーションが主流になっていく中で、まずはほんの少しだけでもいいので、手間暇をかけてみませんか? その一歩を踏み出すだけでも、案外「コミュニケーションコスト」の罠から抜け出すことができるかもしれませんよ。

カテゴリー: Work | タグ: , , , | コメントする

MacBook Air M2にHomebrewをインストールする方法 (macOS Ventura版)


はじめに

2022/10/12にMacBook Air M2を購入しまして、その後あまり何も考えずにmacOS Ventura 13.0にアップデートしてしまってのですが、セキュリティ周りの仕様が変わったせいなのか、こんな感じでHomebrewがインストールできない事態に。

% /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
==> Checking for `sudo` access (which may request your password)...
Password:
==> This script will install:
/usr/local/bin/brew
/usr/local/share/doc/homebrew
/usr/local/share/man/man1/brew.1
/usr/local/share/zsh/site-functions/_brew
/usr/local/etc/bash_completion.d/brew
/usr/local/Homebrew
==> HOMEBREW_BREW_GIT_REMOTE is set to a non-default URL:
/opt/homebrew will be used as the Homebrew/brew Git remote.
==> HOMEBREW_CORE_GIT_REMOTE is set to a non-default URL:
/opt/homebrew will be used as the Homebrew/homebrew-core Git remote.

Press RETURN/ENTER to continue or any other key to abort:
==> /usr/bin/sudo /usr/sbin/chown -R vlayusuke:admin /usr/local/Homebrew
==> Downloading and installing Homebrew...
fatal: '/opt/homebrew' does not appear to be a git repository
fatal: Could not read from remote repository.

macOSの場合、いつの頃からかHomebrewがインストールされるデフォルトのディレクトリが /opt/homebrew に変わったのは知っていたんですけれども、それがGitのrepositoryではないってどういうこと? と思って悪戦苦闘していたんですが、なんとか解決したのでそのメモです。

TerminalをRosettaで起動させるようにする

  • ターミナル.appをFinderから選択
  • ⌘ + iするか、Finderの[ファイル]-[情報を見る]でターミナル.appの情報を表示
  • 「Rosettaを使用して開く」にチェックを入れる

Apple SiliconのMacでも、Intel プロセッサ搭載 Macとの互換性を保たせるためにこれはどうしても必要な設定になります。まずここでApple SiliconのMacBook Air M2でCLIを使うための最低限の準備をします。

Homebrewのリポジトリ設定をリセットする

元々MacBook Air M2のデータは代々引き継がれてきたMacBook Air Intel 2018のものを使用していたので、Homebrewのリポジトリ設定がおかしくなっていたかもしれないので、GitHubのHomebrewに関する同じ現象のディスカッションを参考に以下のコマンドを実行。

% unset HOMEBREW_BREW_GIT_REMOTE HOMEBREW_CORE_GIT_REMOTE

すると、これまでの苦労が何事もなかったかのようにHomebrewのインストールを、公式に書かれているような

% /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

を使用してインストールすることができました。やれやれ。

ちなみにこれ、macOS Venturaにしたからこのようになっているというわけではなくて、Apple Silicon搭載のMac共通で、Homebrewを使用するために実行しておく必要があるおまじないみたいですね。

何はともあれ、開発をしていくにあたって必要なHomebrewが使えるようになり一安心したのでした。

カテゴリー: Private, Work | タグ: , , | コメントする

AWS認定DevOpsエンジニア プロフェッショナル(AWS DOP-C01)に合格しての感想


今年の5月にAWS認定SysOpsアドにミストレーター アソシエイトに合格してから約半年が経過しました。私の中では少なくとも、AWS認定資格のうち、専門分野を除く6つの資格をコンプリートしたかったので、目指すべきはAWS認定DevOpsエンジニア プロフェッショナル(AWS DOP-C01)のみとなり、本格的には2022年8月下旬から受験の準備を始めて、約1か月間の準備を経て、1発で合格することができました。スコアは812点。ギリギリではなかったものの、なんとかなりました。かなり嬉しいです。

どんな風に勉強したのか

AWS DOPも執筆時点では学習参考書は皆無の状態だったので、まずはその時点で刊行されたばかりの「AWS認定資格試験テキスト AWS認定SysOpsアドミニストレーター – アソシエイト」を購入。前回の復習を兼ねてひと回り読み込みました。特にCloudTrail、Config、Inspector、GuardDutyはユースケースがごっちゃになりがちなので改めてどういったユースケースで用いられるのか、またどんなサービスと連携できるのかを中心に復習しました。さらに、AWS DVAの受験からかなり日数が経過していたので「徹底攻略AWS認定デベロッパー – アソシエイト教科書」も並行して購入。Codeシリーズは現在手がけている案件で試行錯誤しながらも使い倒していたので基本的な機能やユースケースを押さえていたのですが、AWS DVAの中でも頻出していたElasticBeanstalkやOpsWorkは使うことがなかったので、やはりユースケースを中心に復習を重ねました。

学習期間は長ければいいというものでもない

当初は10/29を試験日にしていたのですが、学習時間を2ヶ月間に設定してしまうと少しだらけてしまう可能性があったので、AWS SOAでの学習経験が無駄にならないように、あえて試験日を10/1に繰り上げました。

もちろんリモートワーク中心とはいえ仕事はあるし、その分だけ勉強する時間も限られてしまうのですが、仕事の忙しさを理由にしてダラダラ勉強してしまうとそれはそれでよろしくないので、ここは自分の心を鬼にして、あえて追い込むかたちとしました。

長文読解対策は今回は行わず

一通り関連する参考書を読み、今回はBlack Beltの動画を視聴するようにしたのですが、AWS SAPの時とは異なり、今回は長文読解対策は特に行いませんでした。AWS SAPほどの複雑な長文問題が、koiwa改めTechStockを実際に解いてみてそれほど出てこないなというように感じられたからです。とはいえ用件が複雑であることには変わりがないので、問題の中で何を問われているのかは注意して読んでから解くようにしていました。今回の勝因としてはそこの部分を重視しながら学習していったところにあるかなと思っています。

やはり実務は大事

AWS SOAとは異なり、ラボ試験はC01では出題されないため、座学中心での学習になりますが、やはり実務で触るということは他の試験と同じくらい大事なことなのかなと思います。少なくとも、出題範囲となるサービスのコンソールは絶対に触っておいた方がいいです。例えばCloudTrailの場合、API呼び出しが全て記録されているといっても、具体的にどのようにログが表示されるのか、証跡がどのように保管されるのかなど、リソースを作ってしまうと課金されてしまいますが、どの画面でどのように操作すれば要件を実現できるのかは実際に見ておくに越したことはないです。

試験当日の裏話

実は前日に、ローンチしたばかりの案件の打ち上げがあり、終電を逃してしまってタクシー帰宅をしたので、実質的な睡眠時間は3時間程度でした。とりあえず眠かったので、行きの電車の中で20分くらい目を閉じていたらいつの間にか寝てしまっていました。危ない危ない。

加えて試験中に軽い腹痛になってしまったのですが、テストセンターで受ける場合、体調に不調を感じたら、問答無用で試験卓の横にある呼び出しボタンを押して、試験監督の方を呼び出した方がいいです。試験時間が一旦停止するわけではないのですが、ちゃんとトイレに行かせてもらえました。突発的な何かがあるときは躊躇せずに呼び出しボタンを押すのがいいです。頭真っ白になって問題が解けなくなるよりは全然いいです。

次の目標

最初から取得するのは6冠まで、と決めていたのですが、ここまでくると専門分野の領域の試験も受けてさらに知見を深めていくのもいいのかなというように考えるようになってきました。もちろん3年という有効期限を更新していくために、これからもAWS SAPとAWS DOPは繰り返し受けていかなければいけないのですが、どの専門分野が自分にとって必要なのかを考えた上で、そちらの方の受験も検討していきたいなと思っています。

カテゴリー: AWS | タグ: | コメントする

りきひさみねこヴァイオリン・ヴィオラ教室発表会


はじめに

ヴィオラを基礎から叩き直すためにりきひさみねこ先生のご指導を受け始めてから約半年。先生からせっかくだから発表会に出てみませんかと誘われたので、これまでほとんどオケでしか弾いたことがないし、何よりソロだと舞台上で妙にあがる性格なので、そこあたりの克服も含めて発表会に参加することにしました。

課題曲として選んだのはカッチーニの「アヴェ・マリア」。すごい良い曲ですよね。良い曲だからこそなかなか難しいという。発表会に出ると決めたのが7月の後半だったので、かなり高速で、先生にポイントポイントを教えていただきながら準備を進めてきました。

いざ本番

本番の会場は八千代市にある「Chopin Salon」という小ホール。八千代台駅の近くにこんなこじんまりとした素敵なホールがあるとは知りませんでした。そして響きがものすごく良い。良いホールだと思います。

私はリハーサルの40分前に会場入りして、リハーサルを終えた後にいざ本番。

他の生徒さんの演奏を聴いていたんですが、みんなすごいなぁというのが第一印象でした。子供さんが多いのですが、みんなボウイングがしっかりとしていてちゃんと音が聴こえてくるし、しかもみんな暗譜だし。各々の生徒さんが各々の実力の中でしっかり弾くことができているので、すごいなぁと。そうなってくると当然のことながら自分大丈夫なんだろうかとだんだん緊張してきます。

カッチーニの「アヴェ・マリア」、1箇所だけ難所がありまして、そこをリハーサルでもとちったので本番ミスをせずに弾くことができるかどうか正直不安だったので、直前まで譜読みをしながらリズムが合っているかどうかを確認していました。

そして本番。とにかく堂々と弾くことだけに集中していました。懸案の難所も無事にクリア。若干力みがちでヴィブラートならぬ「ビビラート」になってしまったところもありますが、なんとか無事に弾き切りました。いやしかし緊張した中で自分の中ではそれなりにまともに弾けた方だと思っています。もちろん課題はたくさん残っているんですけれども、とにかく大きなミスをすることなく弾くことができたことに関しては自分を褒めたいなと思っています。

本当に、なかなか上達しない自分を支えてくださった、りきひさ先生には感謝感謝です。次の発表会に向けての曲も早速探しましょう! と言ってくださったので、また次回の発表会に向けて、引き続き基礎を固めながらレッスンを続けていこうと思います。

夏の良い思い出がひとつできました。

カテゴリー: Private | タグ: , | コメントする

TerraformでAmazon Pinpointのプッシュ通知設定を行うためのTips


はじめに

業務でモバイルアプリケーションのバックエンド側のAWS環境を構築するにあたって、スマートフォンに送られるプッシュ通知を実装するために、Amazon Pinpointを使用することにしました。Amazon Pinpointを使えば、モバイルアプリケーションへのあらゆる通知機能を一元管理できるのに加えて、開封率などの効果測定もできるため、分析やマーケティングにも役立つということで、ちょっと使ってみようかという話になりました。

私の会社では、AWSリソースをIaCとして構成管理するためにTerraformを使用しているのですが、Amazon Pinpointのリソースとプッシュ通知に用いる

  • Apple Push Notification Service (APNs)
  • Firebase Cloud Messaging (FCM)

の設定を実装する必要があるのですが、そこで色々と沼にハマり、関連するドキュメントもAWS公式のもの以外に見当たらなかったので、備忘録的に、最終的にどういう実装にしたのかを記録しておきます。

Amazon Pinpointのリソースの実装

これは教科書通りで、以下のように実装すれば問題ありません。

# ===============================================================================
# Pinpoint Configure
# ===============================================================================
resource "aws_pinpoint_app" "pinpoint" {
  name = "test-pinpoint"

  limits {
    maximum_duration    = 10800
    messages_per_second = 20000
  }
}

Apple Push Notification Service (APNs)向けのチャネルの実装

最初にはまったポイントがここ。Terraformの公式ドキュメントには、APNsチャネルの実装方式として2つの方式が示されているのですが、サンプルに書かれている“Certificate credentials”(Appleから発行される証明書と秘密鍵を用いる)方式では、何をどうしても何故か、実行時にAppleから発行された正式な証明書ではないというエラーが出てチャネルを作成することができません。秘密鍵の代わりに、パスワードをSSMのパラメータストアに定義してあげて値を渡してもダメ、ならばとパスワードを定数(variables)として定義してあげて値を渡してもやはりダメです。

なので、もうひとつの方式として挙げられている、“Key credentials”(Appleから発行されるバンドルID、チームID、トークンとして用いられる”.p8″ファイル、トークンのキーを用いる)方式で実装し直しました。このうち、バンドルID、チームID、トークンのキーはSSMパラメータストアに以下のように格納します。

# ===============================================================================
# SSM Parameters for iOS (Pinpoint)
# ===============================================================================
resource "aws_ssm_parameter" "apns_bundle_id" {
  name        = "/test/prod/apns-bundle-id"
  description = "The parameter for apns team id with Pinpoint"
  key_id      = aws_kms_key.application.key_id
  type        = "SecureString"
  value       = "${bundle_id}"

  lifecycle {
    ignore_changes = [
      value,
    ]
  }
}

resource "aws_ssm_parameter" "apns_team_id" {
  name        = "/test/prod/apns-team-id"
  description = "The parameter for apns team id with Pinpoint"
  key_id      = aws_kms_key.application.key_id
  type        = "SecureString"
  value       = "${team_id}"

  lifecycle {
    ignore_changes = [
      value,
    ]
  }
}

resource "aws_ssm_parameter" "apns_token_key_id" {
  name        = "/test/prod/apns-token-key-id"
  description = "The parameter for apns token key id with Pinpoint"
  key_id      = aws_kms_key.application.key_id
  type        = "SecureString"
  value       = "${token_key_id}"

  lifecycle {
    ignore_changes = [
      value,
    ]
  }
}

その上で、Amazon PinpointのAPNsチャネル設定を以下のように実装します。

# ===============================================================================
# Pinpoint Settings for iOS
# ===============================================================================
resource "aws_pinpoint_apns_channel" "apns" {
  application_id = aws_pinpoint_app.main.application_id
  bundle_id      = aws_ssm_parameter.apns_bundle_id.value
  team_id        = aws_ssm_parameter.apns_team_id.value
  token_key      = file("./files/key/token_file.p8")
  token_key_id   = aws_ssm_parameter.apns_token_key_id.value
}

この実装方法で、APNsチャネルの登録は無事に成功しました。

Firebase Cloud Messaging (FCM)向けのチャネルの実装

こちらはAPNsチャネルの実装よりも敷居が低いです。Firebaseプロジェクトを新規に作成したときに生成される、FCN用の”サーバーキー”をAPIキーとしてチャネルに組み込んであげるだけでOK、なのですが、ここでもトラップが。

APIキーは当然SSMパラメータストア内に格納したいのですが、格納して実行したところ、”401 Unauthorized”エラーが。なのでものは試しにAPIキーをそのまま引数として代入すると、なんの問題もなくFCMチャネルが作成されます。というわけで、仕方がないので以下のようにAPIキーを実装。

# ===============================================================================
# Firebase Cloud Messaging (FCM)
# ===============================================================================
variable "gcm_api_key" {
  default = "(FCM Api Key)"
}

その上で、Amazon PinpointのFCMチャネル設定を以下のように実装します。

# ===============================================================================
# Pinpoint Settings for Android
# ===============================================================================
resource "aws_pinpoint_gcm_channel" "gcm" {
  application_id = aws_pinpoint_app.main.application_id
  api_key        = var.gcm_api_key
}

この実装方法で無事にFCMチャネルも作成できるようになりました。

謎というか宿題というか

一連の試行錯誤を通じて感じたのは、なぜSSMパラメータストアでは値がチャネル設定側に正しく渡らないのに、variablesにすると値が正しく渡るのかというところです。文字コードの問題なのか、何かしらエンコーディングしてあげないといけないのか、謎は深まるばかり。

ただ、APIキーのような正しく管理しなくてはならない値に関してはできるだけSSMパラメータストアにSecureStringとして管理したいので、そこのところをどうするのか、自分への宿題ということでもう少し試行錯誤してみたいと思います。

そんなわけで、この投稿はもう少し続く、かもしれません。

追記

FCMの実装でSSMパラメータからうまく取得できない理由がわかりました。思い切り、“ignore_changes”を指定していたため、後からAPIキーを追加しても反映されないわけで。

というわけで、以下の実装で無事にFCM向けの設定も無事に通るようになりました。

# ===============================================================================
# SSM Parameters for Android (Pinpoint)
# ===============================================================================
resource "aws_ssm_parameter" "gcm_api_key" {
  name        = "/test/prod/gcm-api-key"
  description = "The parameter for gcm api key with Pinpoint"
  key_id      = aws_kms_key.application.key_id
  type        = "SecureString"
  value       = "${api_key}"

  lifecycle {
    ignore_changes = [
      value,
    ]
  }
}
カテゴリー: AWS, Work | タグ: , , | コメントする

JBUG広島#10 復活と再会にLT登壇しました


はじめに

プロジェクト管理ツールBacklogのユーザ等の有志が参加しているJBUG(Japan Backlog User Group)では全国各地で勉強会を開催しています。ここのところ本業がバタバタしていたり、転職のタイミングだったりしてなかなか参加できずにいたのですが、今回広島での勉強会である「JBUG広島#10 復活と再会」の開催にあたり、募集時点ではCOVID-19の感染状況がやや落ち着いていたことと、なんと言ってもリアルとオンラインのハイブリッド開催ということで、これはリアルの雰囲気を味わわないわけにはいかないぞ! と持ち前の瞬発力がむくむくと出てきてしまい、参加することを決めただけではなく、運営の皆さんにお願いをしてLTします! と宣言して航空券の決済ボタンをポチッとしてしまったのでした。

LT登壇するにあたってのコンセプト

本来は「復活と再会」というコンセプトだったので、それに合わせてLTのお題を決めようかなと考えていたのですが、話のネタを練り込んでいくうちに、今回のコンセプトよりはむしろ、JBUG広島の根底として掲げられている、「皆でよりよい仕事のしかたを探そう」をベースとして、特に4か月前に転職をしたばかりだったので、より良い仕事の仕方やチームの作り方を実現するために、どのようにしてチームに参加していけばうまくいくのだろうかという自分なりの経験に基づくTipsを共有できたらいいな、という方向に舵を切ることにしました。

そんなわけで、LTのお題は「良いチームを作るために心がけていること」に決め、それをもとに自分自身がプロジェクトにJoinした時にいつも心がけていることをスライドに取りまとめていきました。

登壇スライドは以下の通りです。

JBUG広島#10 LT登壇資料

登壇してみての感想

これまでにJBUGでは数回オンラインで登壇したことがあるのですが、リアル登壇は初めてのことで、やはり目の前に聞いてくださる方がいるとなかなか緊張するし噛んだりするものですね。10分間の持ち時間はあっという間な感じでした。

それでも、その場の空気感やダイレクトに登壇内容の感想やフィードバックをいただけたことはとても嬉しく、JBUGが元々持っているポジティブな雰囲気をリアルに体感できたのがとても楽しかったです。また、この状況下で会いたくてもなかなかリアルに会うことができなかった方々ときちんとご挨拶ができたのもとても良かったです。Twitter上などでは交流は普段からしているけれども、初対面というのはなかなか不思議なものです。

みなさんの登壇内容は、今回に関しては共通する点が多かったなと感じました。プロジェクトマネジメントをどうするこうするという方法論というよりかは、プロジェクトをより良くするためのマインドセットや組織やコミュニティの作り方に関する発表内容が多かったですね。やはり現在の状況の中でリアルなコミュニケーションが減っている中で、それでもより良い仕事をするためにどのようにしてコニュニケーションを図っていくかというのは、今の時代だからこその共通のテーマなんだなということを強く感じました。

そういう意味でも、同じ課題認識をしていて、皆さんがそれぞれ思う形で現場からさらにより良くしていこうという意識を持たれている仲間が確実にいるんだなという、ある意味心強さを感じた勉強会になりました。

そして、繰り返しになりますが、リアル登壇って本当に楽しいなと心から思いました。これは本当にやみつきになりそう。

次回の登壇予定はまだ未定ですが、来るべき次の登壇に備えて、また色々とネタを仕入れていこうと思います。

フライトログ

  • 7/9(土) NH677 HND 10:40 – HIJ 12:00 /JA139A/2H
  • 7/9(土) NH684 HIJ 18:50 – HND 20:20 /JA151A/1C
カテゴリー: Work | タグ: , | コメントする