娘と一緒に福岡 & 太宰府へ


すごく珍しいね、と言われることが往々にしてあるのですが、父娘で旅行に出ることが多いです。

コロナ前の2019年11月には韓国ソウルへ行きましたし、コロナに入ってからも、感染状況の谷間を見ながら、特に福岡県を中心に飛行機で旅行に出ています。

そんなわけで、フライトログをかねて簡単に記録。

フライトログ

  • 2022/1/15 NH245 HND → FUK 788 JA802A 4H
  • 2022/1/16 NH258 FUK → HND 788 JA831A 1C

往路のCAさんに、娘が高校に合格してそのお祝い旅行なんですよ、という話をしたら、素晴らしい神対応をしてくださいました。本当にこのような細やかな心配りをしてくださるANAさんは大好きです。

簡単に旅行記録

福岡空港からは地下鉄と11番の西鉄バスを乗り継いで渡辺通にあるホテルに一旦荷物を預け、68-1番の西鉄バスで天神へ向かい、前回食べてとても美味しかった「おむや」さんのオムライスを堪能。相変わらずボリューミーで美味しかったです。

その後西鉄福岡(天神)駅13:00発の大牟田行き特急と太宰府線普通を乗り継いで太宰府天満宮へ。娘が3年間お世話になってきた家庭教師の先生が、今年医師国家試験を受験するため、その合格祈願をしてきました。おみくじは小吉だったなぁ。

で、参道に戻ろうとした時に、カフェの看板がこじんまりと立っているのを見て行ってみようということになり、行ってきたんですが、これが当たりで、居心地が良くとても良い空間でした。イチゴのタルトも美味しくいただきました。「CoRicco」というカフェです。店主さんとリノベーションの話についても盛り上がったり。素敵な店主さんでした。

太宰府からは太宰府線普通と西鉄福岡(天神)ゆき特急を乗り継いで薬院駅で降り、夜に16番の西鉄バスと214番の西鉄バスを使って博多で軽く晩御飯を食べて1日目は終了。

2日目は、どうしても行きたいカフェがあるという娘からのリクエストを受けて、一旦タクシーで博多駅まで出て荷物を預け、JRの線路沿いをてくてく歩いて「AIMAI」というカフェへ。娘はその空間にどハマりしていて、僕はカウンターの窓越しを走るJR九州の電車に見惚れてました。

そうこうしているうちに復路のフライトの時間が迫っていたので、博多から地下鉄で福岡空港へ向かい、サラッと帰ってきました。

娘との二人旅もいいもんだ

何故かわからないけれども、娘とは嗜好とか空気感が似ているところがあるようで、二人旅していても飽きないんですよね。いや父親冥利に尽きるものです。いいもんですよ。これからも感染状況を見つつ、娘と国内色々なところを巡ってみたいですね。

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

AWS請求関連の情報を表示できないようにするためのIAMのカスタマー管理ポリシーを書いた


はじめに

この記事は2022年1月12日現在で発生している現象を元に作成したものです。Amazon Web Services側の仕様変更により記述した記事の内容に変化があるかもしれない点についてはご了承ください。

AWSマネージメントコンソールのホーム画面がカスタマイズできるようになったという知らせを知ったのですが、その影響なのか、元々実装していた、見せてはいけない人に請求関連のサービスの情報を見せないという内容のカスタマー管理ポリシーが効かなくなっていたので、急遽該当するカスタマー管理ポリシーを、以下のように書きました。

作成したカスタマー管理ポリシー

こんな感じです。要点としては、

  • AWSマネージメントコンソール上で請求に関する情報を見せることを明示的に拒否する
  • AWS Budgetsのすべての権限を明示的に拒否する
  • AWS Cost and Usage Reportsのすべての権限を明示的に拒否する
  • Amazon Cost Explorerのすべての権限を明示的に拒否する

という内容になります。もっとこうした方がいいんじゃないのという意見もあるかもしれませんが、結構緊急避難的に90分くらいで仕様確認と実装と動作確認をしたので、その辺は何卒ご容赦を。。。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Deny",
            "Action": [
                "aws-portal:*Billing",
                "aws-portal:*Account",
                "aws-portal:*PaymentMethods",
                "budgets:*",
                "cur:*",
                "ce:*"
            ],
            "Resource": "*"
        }
    ]
}

なんか、AWSさんの作り込んだバグなんじゃないかという情報もちらほら聞こえてきて、しれっと仕様変更が入ってまたこのカスタマー管理ポリシーを直さなければいけないという可能性もあるのですが、その時はその時で、このエントリー上で修正版を共有しようと思います。

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

“会社は「仲良しクラブ」でいい”を読んだ


はじめに

株式会社ヌーラボといえば、プロジェクト管理ツールとして課題をわかりやすく可視化しながら共有することのできる“Backlog”や、構成図やワイヤーフレームを共有しながら作図することのできる“Cacoo”のような、チームやステークホルダーの人たちとコラボレートしながら快適に仕事を進めていくことのできるプロダクトを世に送り出している、福岡発のベンチャー企業として多くの人々に知られています。

ただ単純に知られているといえばよくあるベンチャー企業のひとつとして捉えられてしまうかもしれませんが、「知られている」だけでなく、送り出しているプロダクトを通じて「愛されている」のもこの企業の特徴なのかもしれません。実際にBacklogやCacooには、企業が出しているプロダクトであるにも関わらず、それらを使用する人のコミュニティが存在し、活発に活動が行われているように、企業が開発したプロダクトを通じてより良く仕事ができるようにナレッジを共有している事例が多数あるのも特徴的なのではないかと思います。

そんなヌーラボを率いているのが橋本正徳さん。ベンチャー企業だと、創業者の顔がものすごく際立つという傾向があるのですが、私の知る限りでは、「ヌーラバー」と呼ばれるヌーラボの社員の方々が自律的に活動していく中で、一歩引いてその姿をやさしく穏やかに見守っているようにも見えます。

そんな橋本さんが「会社は「仲良しクラブ」でいい」という本を出されるという話を聞いて、橋本さんの人となりだけではなく、どうしてヌーラボという会社を立ち上げたのか、その中でどんなことを大切にしながらチームを率いているんだろうかというところに興味を抱いて、早速手にとったのでした。

プロジェクトや組織をポジティブに進めることのヒント

組織やプロジェクトには、実際にさまざまな属性の方がいます。プロパーやビジネスパートナーといった所属会社の違い、役職の違い、各々が持っているスキルの違い、考え方の違い、挙げていったらキリがありません。けれども組織やプロジェクトという「集団」として考えるとひとつのまとまりのようなものであって、それがとある目標に向かって進んでいくというミッションを持っています。

とはいえ前述の通り、そこに所属している方たちにはさまざまな個性があるわけで、時にはその個性を押しとどめても集団のために動かなければいけないという状況が往々にしてあるということも、私自身のこれまでの勤務経験の中で痛感してきたというのもまた事実です。

問題はその個性の部分を集団の中でどのように生かしていくと「新しい想定外の1」に変わるのかという、ある意味ポジティブな工夫やマインドの持ち方のヒントが数多く、しかも余すことなくオープンに書いていただいているところが本当に勉強になりました。

特に、私がどちらかというと自分のウィークポイントとして認識しているアンガーマネジメントに関する考え方だけでなく、この状況の中でオンラインでのコニュニケーションが中心となっている中で、「コミュニケーションは上手くいかなくて当たり前」という前提のもとで、「まず相手を信用する」というところから対話や仕事上でのタスクを渡すというアプローチは、現在の仕事の中でも活かすことができる部分が多くあり、自分のこれまでの仕事の仕方を省みてこれは改善できるかもしれないという形で、自分が変えたい側面に対して背中を押してもらうことができました。

きっと、この本を読むと、私だけでなく誰もがこのような気づきを感じるのではないかと思います。橋本さんのことなので、「金言」と書いてしまうといやいやそんなことはないよと言われてしまいそうですが、色々な属性や個性の方々と仕事(だけではないかもしれません。オーケストラなんかもそうかもしれませんね)をしていく中で、どのようにコラボレートしていけば物事が上手く流れてくれるかというエッセンスをたくさんいただいたような印象を持っています。

「偏愛家」というキーワードに関してもとても興味深く思いました。「偏愛家」というと、世間的にはオタク的なちょっとネガティブともとられてしまうかもしれない印象を持たれてしまいがちですが、それも実は個性の一部で、誰もがそのひとつやふたつは持っているのではないかと思うんですよね。

その偏愛的な部分を自律した個性やスキルのひとつとして尊重して生かしながら、集団としてのアウトプットにポジティブに反映するにはどのようにすればいいのかという点に関しても非常に興味深く読みました。

他にも組織やプロジェクトの価値をボトムアップしていく上でのさまざまなエッセンスが詰まっているのですが、これ以上書くとネタバレになってしまうので書くことはやめておこうと思いますが、全体的に思ったのは、これまでプロジェクトの中で働いていくことに対する閉塞感やモヤモヤ感を意外な形で払拭してくれた本でした。

組織論やチーム論に関する書籍は数多く出ていますが、これまで読んできたものに比べて非常に読みやすい印象を受けました。この本をこのタイミングで執筆してくださった橋本さんには心から感謝です。

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

2022年の始まりに寄せて


ご挨拶

新年おめでとうございます。旧年中はさまざまな方に本当にお世話になりました。心から感謝しております。本年も多方面でご迷惑をおかけすることもあるかもしれませんが、どうぞよろしくお願いいたします。

そして、皆様の仕事や生活が、少しでも安全で心穏やかなものになりますように、心からお祈りしております。

今年何したいんだっけ?

あまり今年の抱負的なものを書いてしまうと、色々がんじがらめになってしまうので、あまり強く意識しないようにはしているんですけれども、去年に続いてこの言葉は心に留めておきたいですね。

だれでもキリストにあるならば、その人は新しく造られたものである。古いものは過ぎ去った、見よ、全てが新しくなったのである。

[第2コリント 5:17]

世間的には大変な状況が続いているのは現実です。まだまだ行動も制限されているし、思うようにいかないことも多いかもしれません。トンネルの先が見え始めたかなと思いきや、また元通りになりそうな気配もしていて、多くの人が一喜一憂していることと思います。

けれどもそういった状況だからこそ、日々の生活のどこかしらに小さな喜びというのはあるもので、そういう意味でも、古きものは記憶として残しつつもとりあえず置いておいて、何か新しいことにチャレンジしていったり、新しい環境に敢えて身を置いてみたり、そういった新しいものを取り入れていくことで、気持ちの新陳代謝を図っていきたいなと考えています。

それから何よりも、こういうご時世だからこそ心穏やかに、マインドをできるだけオープンにしていきたいですね。社会を眺めていると、さまざまな要因によっていろいろな分断があちこちで起きているのは確かに事実です。そういう時だからこそ、一人一人が心を広げていく必要があるのかもしれませんね。それは自分とて然り。変に威切ったりしても仕方がないですから。

もうこの年齢ですし、少しずつ心の中の強張りを緩くしていって、まんまるな感じで行きたいと思います。

あとは前のエントリーでも触れましたが、もう少し働き方にメリハリと自由度をつけていきたいですね。こういう時代にあった働き方で、これまで以上に成果を出していきたいなという思いはあります。できるかな?

結局今年何をするのかよくわからない文章になってしまいましたが、2022年の念頭にあたってのご挨拶と思うこととさせていただきます。

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

46歳になって2021年を振り返る


46歳になりました

2021/12/30に無事に46歳になりました。45歳の1年間も色々な方にお世話になったことに、まずは感謝したいと思います。ありがとうございました。

四捨五入すれば見事に50代になってしまうので、アラフィフと呼ばれる世代にまた一歩片足を踏み入れつつあるという感じになるんですかね。体力的というよりも、このご時世もあってなのか、あまり無理はできなくなり、1日の生活パターンが段々と前倒しになってきたような気はします。朝はだいぶ早い時間から活動できるようになってきた一方で、夜は遅い時間まで活動することがかなり厳しくなってきて、徹夜なんてもってのほかというような感じになってきました。

仕事柄、時たま夜間にリリースの立ち会いをしなければならないケースもあったりするのですが、そういう時でも、いつまでも身体が持つというようなことは、正直なくなってきましたね。

このコロナ禍で社会全体の時間の流れ方がだんだん朝方にシフトしてきつつあるのかなという傾向を見ると、その流れに従うかのように朝方にシフトしてきたというのは、もしかしたら良いことなのかもしれません。

2021年の振り返り

その上で2021年をざっくりと全体的に振り返ってみると、特に上半期はちょっとワーカホリック気味になっていたかなというのは正直あります。社会的にはコロナ禍が続き、リモートワークが急激に進むようになって以来、通勤時間というものがほとんどなくなったということは、1日の過ごし方を考えてく上である意味においてはアドバンテージになった一方で、2020年初頭のリモートワーク環境移行時の混乱で身についてしまった、「朝早くから働く」という意識が悪い意味で身についてしまって、結果として、ついつい長い時間働くのが当たり前になってきてしまったというのはちょっと反省しなければいけないのかなと感じています。

もちろん、リモートワークの環境も様々なバックグラウンドを考慮すると人によって様々なので、朝早くから働くということが絶対悪ではないと思うのですが、多分課題だったのは、朝早くからにしようが一般的な勤務時間に合わせようが、家の中だったり、またそれに類する環境の中で、いかにして時間管理をうまくしながら効率的に適度にアウトプットを出しながら仕事をできるかというのが、この時代におけるライフワークバランスを考えていく上で重要な鍵となるのかなということは振り返りながら考えています。この点は来年はもう少し工夫していかなければいけない点ですね。

その一方で、このような働き方をしていく中で、どのようにすれば直接見えない相手に対してもうまくアウトプットを見せることで安心感を得てもらうかということに対しては、相変わらずの試行錯誤はまだ続いているものの、少しずつ前進してきたのかなというように考えています。

コロナ前の働き方って、ある意味「暗黙知」でも十分に相手の意図や考え方が通じ合っていた部分があっただけに、去年に関してはその前提が崩れたことで多少の混乱があったのは、それはそれで仕方がなかった部分があるのかもしれませんが、そこから1年が経過してくると、現在の働き方に対して十分に適応できてくる人と、なかなかそれが難しいという人が明確に分かれてきたような気がしています。これまで暗黙知でもなんとなく仕事をできてきた人が、「可視化」という行為に移行することになかなか順応できないことでそのような状況に陥っているような、そんな感覚をこの1年間の中で感じています。

とはいえ、そういう「人の特性」に近い部分を一気にボトムアップさせようというのは結構厳しくて、その人の考え方や姿勢に応じる形で、柔軟に対応していく必要もあるのかなということも学びました。そこは重要な学びポイントだったのかなということを考えています。

あとは、「集合知」って大事ですよね、ということも改めて強く感じたところではあります。こういう働き方をしている以上、ひとりがスーパースターでもあまり意味がないのかなと。確かにスーパースターであることそのものはすごいことなんですけれども、スターが一方的に引っ張ってくのは物理的にも結構無理があって、チームで働いていく上で、何かに強い人が何人か集まって、お惣菜を持ち寄るような感覚でアイデアを集めていくことが大事な時代になってきたのかなと。そういう意味での集合知という表現を使いました。個として自律しつつも、ある時には知見を共有し合いながら仕事を進めていく、そういう働き方が必要になってきているのかなということを強く感じていますし、そういう観点でのチーミングが必要なのかなということも、今年を振り替えていく中で、同時に感じています。

来年に向けての抱負的なものは年初に改めて書こうかなと思っているのですが、組織を大事にしつつももっと自由に働けるようになってもいいのかなと思っています。

今年も去年と変わらず羽田福岡間を頻繁に飛行機で往復したのですが、約1,000kmという距離を2時間弱で移動できるわけです。そして物理的な距離の制約にとらわれず成果を出そうと思えば成果を出せることも実際問題わかってしまったわけで、そういう意味では組織としての最低限のルールは守りながらも、もっと自由度を持って、その人が成果を出しやすい方向や環境で仕事をしていくのはアリなんじゃないかなと思いました。

このような状況が続いているからこそ、「自分にとっての心地よい働き方ってなんだろう」ということは強く感じます。今年はまだ準備段階ですが、来年以降は自分なりの心地よい働き方を少しずつ実現していく段階に移行していくのではないかなということを考え、目論んでいことになるかもしれません。

46歳も精神的に老いることなく、新しいことをどんどん吸収して変わらず成長していきたいと思っています。

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

MacBook Air (M1, 2020)のディスプレイを交換


MacBook Air (M1, 2020)を相変わらず快適に使っているのですが、2021/12/28の朝、たまたま和室の鴨居にかけていたハンガーにぶら下がっていた洋服が何かの拍子で落下してしまい、ディスプレイに激突。ハンガーの金具の部分がちょうどディスプレイに当たってしまい、無惨な状態に。液晶保護フィルムを貼っていたのですが、内部的に破損をしてしまったようです。

もちろんApple Careの有効期限はふんだんにあるので修理はできるということはわかっていましたが、問題はこの日付。このMacBook Airは在宅勤務にも一部使用しているので、年末年始を挟んでしまうと曜日の関係で年跨ぎになってしまうのと、やはり普段使いしている関係もあるので長期間預かり修理になるとかなり痛いなぁと思いつつ、ちょうど神保町まで出かける予定を入れていたので、東京都内のApple Storeの中でもこの時期一番落ち着いていると思われるApple丸の内のGeniusの予約を取りました。予想通りで比較的早い時間に予約を取ることができました。

運よく店頭に修理部品の在庫があった

ディスプレイの破損に関しては特にGeniusを予約するときの修理希望内容には書かなかったというか、いつの間にかそういった症状を記入する欄がなくなっていたんですかね。無記入の状態で持ち込みしました。

対応してくださったスタッフの方はディスプレイの状態を一瞬見て、そういう状態だということを悟ったようで、手元のiPadをサラリと操作した後に、ちょうど店頭に修理用の交換ディスプレイが「ひとつだけ」残っていて、さすがに当日の修理は厳しいけれども、店頭修理をした上で、翌日か翌々日の手渡しができますよということをおっしゃってくださいました。ものすごくラッキー!

破損した時点でなんとかTime Machineの取得はできていたので、トップカバーに貼っているステッカーが破棄の対象になることに関しては泣く泣く承諾して、店頭修理をお願いしました。

なんか綺麗になって戻ってきた

その日の21時過ぎくらいには修理完了のメールが来たので、翌朝は開店直後にApple丸の内まで再び足を運び、速攻で受け取り。見事に復活をしていて本当に安心しました。入院期間は18時間くらいですかね。修理の速さもさることながら、いつものことですが、丁寧な対応には頭が下がります。

しかも本体側の簡易なクリーニングもしていただけたようで、キートップ周りも綺麗になっていました。ありがたや〜。

で、気になるお値段ですが、Apple Care無しでは60,000円弱するところ、Apple Care対象で技術料のみの請求のため、消費税を合わせても12,900円のみ。持ち歩くことが多いだけに、やはりラップトップタイプのMacを買うときには絶対にApple Careには入っておいた方が、こういう時の安心料になるので安心につながります。

あとは液晶保護フィルムを貼り付ければ完璧ですね。それにしてもスピーディーに対応していただくことができて本当に助かりました。薄さの関係もあってディスプレイ周りは丁寧に扱わなければいけないですね。長く使える機種なので、今後も大事に気をつけながら使っていこうと思います。

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

Kinesis AgentをCloudWatch Alarmと連携して自動的にプロセス再起動するLambda関数を書いた


困っていたこと

ログの収集と分析のためにAmazon Kinesis Data Firehoseを使用してS3バケットにストリーム形式で流し込むというデザインパターンは半ば定番のようになっていて、お仕事で普通に使用しています。

EC2インスタンス上でKinesis Data Firehoseを使用するためには、Kinesis Agentをインストールして必要なログをKinesis Data Firehose経由でS3バケットに流し込んでいるんですが、どうもこのKinesis Agentのプロセスが、流そうとしているログファイルを掴みっぱなしになって、その結果、EBSボリュームがストレージフルになり、EC2インスタンスをいちいち停止 & 起動しなければいけないという課題に遭遇していました。

ワークアラウンドとして、Amazon CloudWatchのメトリクス監視の中に、EBSボリュームの状態を監視するメトリクスを追加して、閾値を超えたらEC2インスタンスを手動で停止 & 起動するというワークアラウンドまでは確立したのですが、それだとちょっとなぁということで、何かいい方法はないかと考えていたところ、「AWS Lambda で CloudWatch アラームからの障害対応自動化」という記事を発見して、これを少しカスタマイズすれば、いちいちEC2インスタンスを停止 & 起動しなくても、Akinesis Agentのプロセス再起動だけで回避できるんじゃないの? という結論に達し、Lambda関数を少しカスタマイズさせてもらいました。@quickguardさん、ありがとうございます。

事前準備とLambda関数

事前準備は基本的に、引用元の記事とほとんど同じです。もちろんEC2インスタンスにはKinesis Agentがインストールされていることが前提です。もしインストールされていなければ、以下のコマンドでインストールします。ちなみに環境はAmazon Linux2です。

sudo yum install –y aws-kinesis-agent

EC2インスタンスはGravitonを使用しているので、SSM Agentをインストールするコマンドはこちら。

sudo yum install -y https://s3.ap-northeast-1.amazonaws.com/amazon-ssm-ap-northeast-1/latest/linux_arm64/amazon-ssm-agent.rpm

ここまでできたら、EC2インスタンスに対してSSM Agentが使用できるようにIAMロールを設定してあげて、Lambda関数を実装します。Lambda関数の実装に関しては前掲の記事通りです。

カスタマイズしたLambda関数はこんな感じです。っていうか結果を返却する処理、例外処理と、実行するコマンドが違う以外はほとんど実装内容変わっていません。ごめんなさい。。。

import boto3
import json
import logging
import traceback
import datetime

logger = logging.getLogger()
logger.setLevel(logging.INFO)

def lambda_handler(event, context):
    
    ssm = boto3.client('ssm')
    
    logger.info("Event: " + str(event))
    
    message = json.loads(event['Records'][0]['Sns']['Message'])
    logger.info("Event: " + event['Records'][0]['Sns']['Message'])
    
    instanceId = message['Trigger']['Dimentions'][0]['value']
    alarmName = message['AlarmName']
    newStateValue = message['NewStateValue']
    newStateReason = message['NewStateReason']
    logger.info("%s - %s state is now %s: %s" & (instanceId, alarmName, newStateValue, newStateReason))
    
    try:
        ssm.send_command(
            instanceIds = [
                instanceId
            ],
            DocumentName = "AWS-RunShellScript",
            Parameters = {
                "commands": [
                    "service aws-kinesis-agent restart"
                ],
                "executionTimeout": [
                    "3600"
                ]
            }
        )
        
        return {
            "statusCode": 200,
            "message": 'restarting Kinesis Agent: %s' & datetime.datetime.now(datetime.timezone(datetime.timedelta(hours=9)))
        }

    except Exception as e:
        logger.error(e)
        logger.error(traceback.format_exc())
        return {
            "statusCode": 500,
            "message": 'An error occured at restarting Kinesis Agent process.'
        }

根本的な解決のためには

これでワークアラウンドから一歩進んで、もしもCloudWatchでEBSボリュームのストレージ使用率の閾値が上がった場合は自動的にKinesis Agentのプロセスを再起動するという自動化は達成できた感じなんですけれども、そもそもKinesis Agentがファイルを掴みっぱなしにするという根本的な問題が解決されていないというところがなんとも。

Apache Log4j2の問題が収まった段階で、このLambda関数のお役目も終了になってくれるといいなぁと願っています。

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

ANA Pocketを試してみることにした


このコロナ禍で航空会社各社は需要の喚起だけではなく、ビジネスの多角化にも挑んでいるわけで、ANAはポイントを主体としたビジネスを展開しようとさまざまなサービスを打ち出しているみたいですね。

そんな中で個人的にちょっと楽しみにしていたのがANA Pocketです。なかなか飛行機に思うように搭乗できない中でも、日常の生活の中で移動した履歴がマイルやコインに交換できるなんてなんて素敵なサービス! しかも在宅勤務主体の中で、身体を動かすことも含めて移動するということがかなり少なくなっているだけに、少しでも散歩なりなんなりして身体を動かしたり、ちょっと気分転換に、リスク対策をしながらもどこかに移動しようかなというモチベーションにもつながるのかなと思います。

ANAマイレージクラブに登録している人であればその恩恵は確実に受けられるのではないかと(もちろんへんてこりんなマーケティング要素が入り込んでこなければの話ですが)。

正式なサービス開始は2021/12/20からだったようなのですが、アプリケーションを実際にダウンロードできるようになったのが2021/12/21だったので、早速ダウンロードしてみました。

登録方法はとても簡単

登録方法は至ってシンプルで、メールアドレスとパスワードを設定すると、設定したメールアドレス宛に認証コードが届くので、これを入力するだけですぐに使えるようになります。合わせてAMC会員の人は、[メニュー] → [アカウント情報] → [アカウント連携]でAMCの会員情報を紐づけるだけ。これで通常のPocket会員になることができ、すぐに使用開始できます。

マイルと交換できるようになるためにはANA Pocket Pro会員になる必要あり

まぁここは商売というか、サブスクリプションに近いものがありますよね。通常のPocket会員だと、貯まったポイントをクーボンとANA Skyコインに交換できるのですが、マイルに交換できるようにするためには、月額550円でANA Pocket Pro会員になる必要があります。月額550円が高いか安いかは、移動頻度と、あえてマイルに交換したいかどうか次第なのではないですかね。

というのも、もちろん日常の移動でマイルが貯まること自体は嬉しいことなのですが、会員種別によって積算されたマイルに対するANA Skyコインへの交換比率は変わってくるので、もしも一般会員なのであれば、貯まったマイルで特典航空券(基本的には特典航空券で搭乗したフライトに関してはマイルが積算されません)に交換するよりも、初めからANA Skyコインに交換しておいて、そのコインを航空券購入に充当した方が個人的にはお得なのかなと思います。

私の場合は国内線は基本的にANA便しか使わないのと、ANA好きということもあってPro会員になったのですが、そこまですることもないかなという方は、通常のANA Pocket会員のままでもいいんじゃないかと思います。

というわけで早速使ってみた

とりあえずちょっと近所まで歩いてきたのですが、iOSのヘルスケア機能と連動しておけば、自動的に移動した距離がポイントに反映されるようになります。大体、50m移動するごとに1ポイントが加算されていく感じですかね。なので、短距離であってもこまめに移動していけば、徒歩での移動だろうが、自転車での移動であろうが、確実にポイントは加算されていくんじゃないかと思います。

まだ電車での移動はしていないため、特に身体を動かさずに移動した時に、位置情報としては履歴が記録されるものの、どのくらいのポイントが加算されていくのかはまだ試していません、というか最近電車には1週間に1回くらいしか乗らないからなぁ。実際に乗って移動した時にどうなるのかは別途追記ということで。

位置情報サービスでもあるので、今後コロナと付き合いながら社会生活を送っていくにあたって、飲食店などと連携して、利用することでポイントを積算していくなどして、社会経済がうまく循環していくといいですね。その辺りの試金石になるアプリケーションなんじゃないかなと思っています。今後の展開に期待です。

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

Amazon Auroraの自動停止をAmazon EventBridge + AWS Lambdaでコントロールする


きっかけ

個人のAWSアカウント上でハンズオンのために基本的なAWSリソースが使用できるようにしていて、Amazon Auroraもその対象に含めているのですが、テスト用でr5.largeの最低限の構成でAuroraクラスターを起動しているだけでもそれなりのコストがかかってしまうのに加えて、Amazon RDSにしてもAmazon Auroraにしてもそうなのですが、手動で停止しても7日間経過すると自動的に起動するという謎仕様になっているので、コスト削減のためにも、必要な時だけ起動して、それ以外は定期的に起動状態をチェックして、もしも起動していたら止める、という仕組みを作れないかなと考えていました。

で、ふと気が付いたのですが、そういえば前回Amazon EC2インスタンスの起動停止をAmazon EventBridge + AWS Lambdaでコントロールする仕組みを既に導入していたので、これをそのまま応用すればいいじゃない、ということで、サクッと実装してしまおうということになったのでした。

Lambda関数作成時にまずは実行ロールの設定を

例によってLambda関数を作成していくのですが、今回は気をつけなければいけない点がひとつ。Lambda関数からAuroraに対する実行ロールを作成しなければいけません。一旦デフォルトの設定で実行ロールを作成した場合は、作成されたロールに対してIAMポリシーを追加してあげる必要があります。でないと、Lambda関数を実行した時点でアクセス権限エラーが出力されます。

今回はひとまず、Amazon Auroraがプライベートサブネット上に構成されていることと、インターネット側からLambda関数が実行されることがないので、取り急ぎAWS管理ポリシーであるAmazonRDSFullAccessをつけてしまいます。ただし、これはあくまでもとり急ぎなので、最小権限の原則に基づいて後々必要な権限のみをアタッチするカスタマー管理ポリシーを実装することにしましょう。

Lambda関数の実装

基本的にやっていることは、EC2インスタンスの自動的な起動停止と一緒で、Auroraクラスターに付与したタグを持ってきて、タグに合致するAuroraクラスターを丸ごと停止させてしまいましょう、という内容です。コードはこちら。

import boto3
import logging
import traceback

logger = logging.getLogger()
logger.setLevel(logging.INFO)

def lambda_handler(event, context):

    region = event['Region']
    client = boto3.client('rds', region)

    rds_clusters = client.describe_db_clusters().get('DBClusters', [])

    print ("Found " + str(len(rds_clusters)) + " Aurora Clusters")

    for rds_clusters in rds_clusters:

        try:
            cluster_status = rds_clusters['Status']
            cluster_ids = rds_clusters['DBClusterIdentifier']
            cluster_arn = rds_clusters['DBClusterArn']

            print ("DBClusterIdentifier is %s and Status is %s" % (cluster_ids, cluster_status))

            tags = client.list_tags_for_resource(ResourceName=cluster_arn).get('TagList', [])

            print ("Tags is %s" % tags)

            for tags in tags:
                if tags['Key'] == 'AutoStop':
                    print ("Current instance_state of %s is %s" % (cluster_ids, cluster_status))

                    if cluster_status == 'available':
                        client.stop_db_cluster(DBClusterIdentifier=cluster_ids)
                        print ("Aurora Cluster %s comes to stop" % cluster_ids)
                    else:
                        print ("Instance %s status is not right to start or stop" % cluster_ids)
            return {
                "statusCode": 200,
                "message": 'Started automatic stop Aurora clusters process. [Region: {}]'.format(event['Region'])
            }

        except Exception as e:
            logger.error(e)
            print(traceback.format_exc())
            return {
                "statusCode": 500,
                "message": 'An error occured at automatic stop Aurora clusters process.'
            }

ここで躓いたポイントとしては、Auroraクラスターに設定したタグの情報を取得してくること。EC2インスタンスの時は、

responce = client.describe_instances(Filters=[{'Name': 'tag:AutoStartStop', 'Values': ['1']}])

でいけたのですが、同じ要領でコードを書いても、テスト実行時にどうもうまくいかなかったので、一旦起動しているAuroraクラスターの一覧を取得して、各クラスターごとに、arnを取得してそこに紐づいているタグを取得してくる方式に実装方法を変更しました。さらに、EC2インスタンスの時はタグのvalueの値によって制御していましたが、今回はタグのkeyが存在するかどうかで判定する方式に変更。

あとはEventBridgeをトリガーとしてcron式とlambda_handlerに送り込むイベント引数を追加して設定し、実行に失敗した時だけ自分の携帯電話にSMSを送信するAmazon SNSトピックを設定して終了です。

この方法、今回はAuroraクラスターに対して実行しているため、stop_db_clusterメソッドを実行することでクラスターに紐づいているrdsインスタンスを一気に落としていますが、Amazon RDSを使用している場合でも、ここのメソッドを書き換えてあげるだけで各々のrdsインスタンスを自動停止したいときに適用できるので使い回しが効くと思います。

自動化する方法は意外とハードルが低いかも

もちろん適切なマネージドサービスがあればそれを使うに越したことはないのですが、コードの実装に対する気分的なハードルを下げることと、Lambda関数の仕組みの理解のためにも、せっせとPythonを書いてこのような形で自動化できそうな仕組みは可能な限り自動化していこうと思います。

まぁエレガントではない泥臭い方法なのかも知れませんが、このようなアプローチでいけば、さまざまな処理を自動化していく方法は意外とハードルが低いのかもしれませんね。

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

今更ながらApple Magic MouseとMagic Keyboardを仕事用に導入


はじめに

コロナ禍で在宅勤務制度が本格的に始まってからかれこれ1年8ヶ月が経過しました。当初は会社から貸与されたPCで仕事をしていたのですが、まぁこれがなんとも使いにくかったのと、PCの管理が結構大変なので、自宅で眠っていたMacBook Air(Retina, 13-inch, 2018)を引っ張り出し、VMware Holizon Clientを使用してオフィスに置いてあるPCにリモート接続するように運用を変更しました。ついでにひょんなきっかけで絶妙なタイミングでHP M22f FHDディスプレイが手に入ったので、個人的には在宅勤務環境はほぼほぼ出揃った感じになりました。

なんで今更マウスとキーボードを?

そんな感じで環境はだいぶ整ってきたのですが、MacBook Air(Retina, 13-inch, 2018)で仕事している上での欠点って、やっぱりバタフライキーボードなんですよね。普段使いしている程度であれば慣れるのですが、これを仕事で1日中使い続けているとキーストロークの浅さがなかなか辛い。そして辛いので肩が凝ってくるという。

とはいえWindowsの環境に合ったキーボードを探してみたところ、どうも一長一短でなかなかこれというものがない。まぁキーマッピングはうまく変換すればいいので、できるだけ使い慣れたものをということで結果的に購入したのが、Apple謹製のMagic MouseMagic Keyboard。Magic Keyboardは既にTouch ID対応のものが出ていますが、仕事用に使用しているのはIntelなので、まぁコストパフォーマンスを考えても普通のものでもいいでしょって感じで。

あとは、Windows環境上で仕事をするのにマウスって必須ですねぇ。もちろん、Macのトラックパッドはいろいろな意味で優秀なので、違和感ない操作感はあるのですが、それでも台画面上で操作しようとするとそれなりにストレスがかかるもので。

そういったストレスを少しでも軽減するためにも、マウスは必要な感じですね。

だいぶ楽になった

ここまで一通り取り揃えたことで、在宅勤務もだいぶ楽になってきました。何が楽になったかって、狭いデスクの上にモニターとMacBook Air2台という細々した状況がだいぶすっきりしたこと。MacBook Air (M1, 2020)の方は音声用に使用しているので、1台は置いてあるのですが、MacBook Air(Retina, 13-inch, 2018)の方はクラムシェルモードにしてデスクとは別の場所に置いているので、スペースがすっきりした分、執務スペースが増えて結構仕事の効率が上がってきました。

やっぱりデスク上を効率的に使用できるのって、在宅勤務を進めていく上では大事ですね。

これからも在宅勤務は続くので、改善できるところを少しずつ改善していって、快適に生産性が上がるように工夫していきたいと思います。

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