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 | タグ: , , | コメントする

WordPressをさくらインターネットからAmazon Lightsailに移行した話


はじめに

このWebサイト、実は2010年からさくらインターネットの共用ホスティングサーバで長らく運用してきたのですが、最近色々あって復旧作業に手間取っているうちに、何を思ったのかWordPressの環境を吹っ飛ばしてしまったのです。お恥ずかしい限り。

パブリッククラウドに関わる仕事をしている割には、自分の環境は旧来のホスティングサーバということもあって、Amazon Web Servicesに移行しようかなと思いつつも、相応の構成でガッツリ組もうとするとそれなりにコストがかかるし、とはいえホスティングサービス使い続けるのもなぁということであれこれ考えていました。

Amazon Lightsailに関しては、AWSマネージメントコンソールのログイン画面で当たり前のように表示されるので名前は知っていました。ただその内容については全く知らず、というか要はちゃんと調べていなかったんですね。

で、実際にどういったサービスかを調べてみてびっくり。驚くほど低コストで、自分のような小規模なWebサイトの運用に使えるじゃん! ということで、さっさと乗り換えることにしたのでした。

移行は超簡単

簡単というか、ma-ya’s CREATE / WEB DESIGNさんの記事、”[Lightsail] さくらインターネットからAWS LightsailにWordPressを最速で移行する – スモールスタート編“と、Naoki Sekiguchiさんの記事、”さくらのVPSから Lightsail へ引っ越した | Like@Lunatic“に丁寧に解説されている通りのステップで、あっという間に移行が完了してしまいました。

上記2つの記事には本当に感謝しています。ありがとうございます!

つまずいたポイントがあったとすれば、AWSのお約束で、Lightsail側のUIが変わったせいなのか、ドメインのDNSの向き先変更を行うときに、Aレコードの追加の仕方がよくわからなくてネームサーバーの設定だけを先にさくらインターネット側にしてしまったことで、名前解決ができなくなり、Lightsail側の設定をよくよく見てみたら、しれっと[レコードの追加ボタン]が存在していることに気付いたので、慌ててAレコードを追加してあげてWordPressがインストールされているインスタンスの再起動をしたら、きちんと名前解決できるようになったといったくらいでしょうか。

どうもDNS周りのことはなかなか覚えられないだけに、ここはもうちょっと勉強しなきゃなぁとか思いました。

そこを乗り越えればサクサクで移行作業はおおむね60分程度で完了。無事にお引越しが完了しました。後はさくらインターネット側のお掃除をしてあげれば終了です。

使用していたWordPressのプラグインのうちの一部がどうもうまく動かないなぁという課題が残っていますが、それは後々調整していく感じで。

個人で使用するには十分なスペック

使用しているインスタンスは1GB RAM、1vCPUなので、EC2インスタンスで初年度無料枠で使用できるt2.microのインスタンスタイプと同等ですし、現時点では片方のAvailability Zoneにしか配置していないので、仕事柄若干不安はあるのですが、大規模なAZ障害でも起きない限り、個人利用するという前提で考えれば十分なスペックと環境なのではないかと思います。

後この先できることとすれば、ドメインも移管して、Amazon Route 53に移そうかどうしようかというところですかね。これができれば個人で利用している学習用のAWSアカウント上のリソースと連携して色々と実験することができるし。ここはこの先かかってくるコストとのご相談というところで。

終わりに

パブリッククラウドの環境を使ってみたいなぁと思いつつも、コストを考えて躊躇していて、なおかつAWSに関して少しでも知識を持っている人にとっては、Amazon Lightsailを使用するという選択肢は十分にあり得るのではないでしょうか。もちろん環境を維持していくことに関しては責任共有モデルが(多分)適用されるので、それなりに必要なことがあるかなと思いますが、まずはお手軽にAWSの環境を体験してみたいという人にとって絶好の選択肢なのではないかと考えています。

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

仕事で心がけていることと知識や経験の共有手段


はじめに

先日、勤務先の事業部が月に1回発行している社内報に、インタビュー記事を寄稿する機会があったのですが、あまりにも文字数が多過ぎたらしく、一部割愛されてしまったので、この機会なので自分の仕事に対するスタンスというか、心がけていることをアウトプットする意味でも、ここに書き留めておこうと思います。

心がけていること

  1. 基本的に新しいもの好きであること
  2. どんな役割の人の経験や話も自分の勉強になると思って傾聴すること
  3. 自分が得た経験や知識をできるだけ共有すること

1に関しては、まぁそうですよね。ITの世界はとにかく移り変わりが激しいし、トレンドが大きく変わってくるわけで。特にプラットフォームの世界ではオンプレミスな環境からのクラウドシフトが急速に進んでいっていて、たまたま私の場合はAmazon Web Servicesに関わることでそのシフトの波に乗っているのですが、それでも日々発表される新しいサービスやアップデートに対して追いついていくのに必死なわけで。

それでも新しいものに興味を持って、それが何ものであるのかを理解しておくというのはとても大事なことなんじゃないかと思っています。

2についてもそれに関連することなのですが、年齢や経験年数、職位に関わらずその人の経験やそこから学んだことに関しては、真摯に傾聴することが大事なんじゃないかと思っています。この辺り、座学の世界ではなかなか得られるものではないし、他の人の経験を糧にすることで自分の知見も自ずからアップデートされていくので、経験に基づく学びというものを傾聴して理解することは大事なんじゃないかと。決して基礎的なことだからと鼻で笑うというのはNG。

3が一番大事なことなんじゃないかなと思っています。いわゆる集合知の世界ですよね。もちろん万能な人がこの世の中にいればそりゃすごいなと思うんですけれども、そういう人がたくさんいるわけではないし。けれども各々の人がそれぞれに得意分野を持っていて、いわばネタを持ち寄るような形で共有し合うことが、結果としてチームのボトムアップにつながっていくんじゃないかなと思っています。

そのためにも、まずは自分が得た知識や経験を、手段はどんな方法でも構わないので共有していくこと。自らがナレッジを共有していくために動いていくこと、それがとても大事なことなのではないかなと思っています。

経験や知識を共有するための手段

手段としてはストックとフローはとても意識しています。タイムリーな情報をフローとしてタイムリーに共有するのであれば、Slackなどのビジネスチャットを使って自分の理解を交えながらささっと共有、もしも自分の得た知識や経験を、プロジェクトの先々に対して何かしらの形でストックとして記録に残しておくのであれば、Confluenceに書き留めておくようにします。情報を共有するためのリポジトリを作るということですね。

Confluenceはアジャイル型の開発を進めていく上では非常に有用なツールなのですが、そういう手法でなくても、文章として散らばってしまいがちな情報をWikiのようにリポジトリ管理するにはものすごく便利な手段だと思っています。誰かが書き記した情報をアップレートしたいと思えば誰でもアップデートすることができるし、コメントを書いていくことでFBにもつながる。プロジェクトをボジティブに進めていく上ではとても使いやすいんじゃないかなと思います。

Confluenceはお仕事で使っているので残念ながら実例をお見せすることができないのですが。

その代わりに、個人的にはそのネタを仕込むための手段として、Day OneというmacOS向けのアプリケーションを使っています。元々はライフログをローカルで書き留めておくためのアプリケーションなのですが、マークダウン形式で整理しながら書き留めていくことができるし、時系列やタグで管理できるので、これなんだっけ? と振り返って情報共有のネタにするときにとても重宝しています。このBlogのネタも、大抵はここから引っ張り出していることが多いです。

もちろんそれぞれにストックとして記録に残しておく手段があると思うので、そこはやりやすい形で全然問題がないと思うのですが、ちょっとだけご紹介ということで。

アウトプットに対するフィードバックを期待しすぎないこと

案外これ大事なんですけれども、自分がアウトプットしたことに対するフィードバックを過剰に期待しすぎないことも大事です。仮に自分が10個のアウトプットを出したとしても、それに対して10個のフィードバックが返ってくることは基本的にないです。せいぜい2個か3個くらいかなと思います。10個返ってくることを過剰に期待しすぎると、逆にそのことが重荷になったり、ネガティブな感情を抱いたりしてしまうことになるので、そこは程々に。

じゃあ結局は自己満足の世界なのかと言われてしまうとそのバランスを取ることがものすごく難しいのですが、けれどもこういった取り組みって誰かが始めないことには将来的に集合知として育たないことになってしまうので、自分はその種まきをしているんだっていうくらいに思っておけばいいんじゃないかと思います。

最後に

まずは自分の力でできることを種まきしていけばいいんだと思います。短期的にそれが育たなくても、少しずつ根を張って、結果として未来のどこかでそのナレッジが生かされるようになれば、目的は果たすことができると思うので。

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

Amazon DevOps Guru for RDSを試してみる


はじめに

2021年のAWS re:Inventでも魅力的な新しいサービスが発表されたり、サービスのアップデートが発表されたりと、日々興奮しつつ寝不足の日々を過ごしておりました。

数ある発表の中でも個人的に気になったのが、Amazon DevOps Guruが、Amazon DevOps Guru for RDSとして、Amazon Auroraに対応してくれたこと。ここのところお仕事で、WordPressをホストしているAmazon Auroraのパフォーマンス問題に悩まされており、それを一発で解決する手段として、これは使えるんじゃないかとピンときて、早速設定の仕方だけでもハンズオンしておこうとなったわけです。

Amazon DevOps Guru for RDSで何ができるのかを平たく書くと、機械学習(Machine Learning)を使用してAmazon Auroraクラスタを構成するrdsインスタンスに関する各種メトリクスを分析し、ホストリソースの過剰使用、データベースのボトルネック、SQL クエリの誤動作といった、パフォーマンスに関連するさまざまなデータベースの問題を自動的に特定して分析してくれること。

特にWordPressをAWS上でホストしている場合、コンテンツの生成はほとんどの場合SQLクエリによって動的に生成しているので自ずとAmazon Auroraに対するパフォーマンスをチューニングすることが不可欠になってきますし、単純にAmazon Auroraクラスタを構成するrdsインスタンスだけでなく、SQLクエリの改善も必要になってきます。そのためにも有効な手段なのではないかということで、ちょっと試してみようかということになりました。

設定方法

設定方法は至って簡単だったりします。ここではサンプルのAmazon Auroraを使用して設定方法をハンズオンしてみます。

分析対象のrdsインスタンスにタグをつける

ここではテスト用のAuroraクラスタと、シンプルなrdsインスタンスを作成していますが、本番のワークロードでもやることは同じです。

以下の通り、”key: Devops-Guru-*”, “value: True”というタグの設定を、分析したい対象となるrdsインスタンスにまずは仕込んであげます。なぜかというと、本番ワークロードでは多数のAWSリソースが動いているため、Amazon Auroraのみにスコープを絞り込んで分析を行いたいためです。

先に分析対象のリソースを絞り込んでおく

次に、Amazon DevOps Guru上で、分析に必要なコストを圧縮するために、[設定]-[Analysed resource]で分析対象のリソースを絞り込みます。

  • Choose resources to analyzeから、[Tags]のラジオボタンを選択。
  • [Tag key]のプルダウンリストの中に、先ほど指定した”Devops-Guru-RDS”が選択できるようになっているため、これを選択。
  • Choose tag valuesから、[Choose specific tag values]のラジオボタンを選択。
  • [Select tag values]のリストの中から、先ほど指定した”true”のチェックボックスを選択。
  • [保存]ボタンをクリック

これで設定完了です。あとはダッシュボードから有効化するだけ。ちなみに、分析対象のリソースは、リソースが削除されるまで有効化されっぱなしになるので十分にご注意ください。

一応念のためコスト算出もしておく

それでもコストが気になるなっていう人は、コスト見積りツールからコストを算出しておきましょう。やり方はほとんど似ていて、

  • リソース分析の見積りカバレッジから、[Tags on AWS resources in the current Region]ラジオボタンを選択。
  • [Tag key]プルダウンリストの中に、先ほど指定した”Devops-Guru-RDS”が選択できるようになっているため、これを選択。
  • [Tag value]プルダウンリストの中に、先ほど指定した”true”が選択できるようになっているため、これを選択。
  • [月額コストの見積り]ボタンをクリック。

これでコストの算出が開始されます。

ここまでできたら、レポートが出力されるまで気長に待ちましょう。初回レポートの出力には、ワークロードにもよりますが数時間かかることがあります。

終わりに

今回はサンプルのAmazon Auroraで試してみたため、全然問題が発生しなかったのですが、ある程度のトランザクションのあるAmazon Auroraクラスタ上のrdsインスタンスでは、パフォーマンスに関するなんらかのレポートが出力されます。もちろん出力されたタイミングでSNSトピックによって通知を出力することも可能です。

お仕事で絶賛お試し中なところでもあるのですが、この存在が特にWordPressをAWSを用いて運用改善していく際の大きな助けになればいいなと思っています。

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