先に書いた、
読み直したら技術に関する具体的な記述が何もないので、補足しておきます。
MySQL（Aurora MySQL 互換含む）に関する技術
わたし自身は DBA でも何でもないのでプロの方々と比べられても困るのですが、勤務先の中ではまあまあ詳しいほうではあるので、SRE 活動の一部として、インフラに悲鳴をあげさせないテーブル設計と SQL の書き方について、自分で復習するとともに、メンバーへの浸透をはかっていきます。
あと、遅れに遅れている utf8mb4 化対応も（メンテナンス停止時間の短縮が課題です）。
と同時に、仕事とは何も関係がないのですが（勤務先のシステムは Amazon Aurora MySQL 5.6 互換版なので）、引き続き MySQL 8.0 の動向は追っていきます。
MySQL 以外のデータストアに関する技術
これも仕事と趣味半々です。
まずは勤務先のシステムにキャッシュを取り入れるべく、Redis の導入を進める予定です（SRE 活動の一部でもある）。本当はキューの導入のためさらにもう一歩先に進めたいのですが、とりあえず今年は着実に一歩だけ踏み出す（RDBMS やオブジェクトストレージ以外のデータストアも利用する）ことにします。
もう一つ、RDBMS については「適材適所」ということで、CQRS も視野に入れつつ MySQL だけではなく PostgreSQL の技術も少し研究していこうかと（夜間 VACUUM に敗れて以来十数年ぶりの再チャレンジ）。それもあって昨年のアドベントカレンダーには 3 本も Aurora PostgreSQL 互換版の記事を書きました（注：ほとんど中身はありません）。
※ほとんどウケなかったので、LT にして成仏させました。
※この話の「つづく」の結論は自分なりに出してみたのですが、さすがに LT の続きの需要はないかな…。
AWS 環境のアカウント分離
オンプレ移行のため構築を優先して 1 アカウントで運用してきた勤務先の AWS 環境を、複数アカウントに分離する作業に取り掛かります（というか昨年秋から取り掛かっています）。
前々から気にはしていたのですが、別の開発業務を優先してこの作業が停滞している間、ついに「本番環境とステージング環境を取り違えてオペレーションする」事故が発生してしまいました。
昨年を含め、ここ数年でアカウント横断管理しやすいサービスがかなり増えたので、上手に活用して本番・ステージング・開発の環境分離を進めていきます。
※これ↓なんかはうれしい新サービスです。
AWS Transit Gateway – アマゾン ウェブ サービス
これを進めるのにまず間違いなく CloudFormation が必要になりますが、昨年はかじった程度で終わったので今年は本格的に取り組みます。
たぶん他にも取り組むと思いますが、とりあえずはこんなところです。
