継続は力なり

タイトル通り定期的な更新を心掛けるブログです。

胸熱! Aurora MySQL in-place upgrades 機能を使って MySQL 5.6 => 5.7 にアップグレードする

タダです.

re:Invent 中に Aurora MySQL 5.6 から 5.7 へアップグレードすることが容易になるアップデートが出るアナウンスがあり,業務で担当しているデータベースは MySQL 5.6 なので期待していたら遂に出ました! MySQL のバージョンの追随をしていきたいと思っており,スナップショットからの復元不要かつデータベースのデータを移行したりが不要でアップグレードできるんじゃないかと期待していたので, Aurora MySQL の in-place upgrades 機能を試してみました.検証してみた内容この記事にまとめていきます.

aws.amazon.com

機能の概要

in-place upgrades 機能の特徴はバックアップによる復元でのバージョンアップではなく数クリックでアップグレードできるところが特徴です.

Instead of backing up and restoring the database to the new version, you can upgrade with just a few clicks in the Amazon RDS Management Console or by using the AWS SDK or CLI.

To upgrade to Aurora MySQL 5.7, select the "Modify" option on the AWS Management Console corresponding to the database instance you want to upgrade, choose the version of Aurora MySQL 5.7 you want to upgrade to, and proceed with the wizard. The upgrade may be applied immediately (if you select the "Apply Immediately" option), or during your next maintenance window (by default). Please note that in either case, your database cluster will be unavailable during the upgrade and your database instances will be restarted.

更にドキュメントによるとすべてのデータを新しいクラスタボリュームにコピーする必要がなく,アプリケーションの構成変更を最小限に抑えアップグレードされたクラスタのテストも少なく抑えられるとあります.また, in-place upgrades 機能の仕組みとして Aurora クラスタをシャットダウンし,トランザクションロールバックや undo purge などの未処理の操作を完了させるのも特徴です.

This technique keeps the same endpoint and other characteristics of the cluster. The upgrade is relatively fast because it doesn't require copying all your data to a new cluster volume. This stability helps to minimize any configuration changes in your applications. It also helps to reduce the amount of testing for the upgraded cluster, because the number of DB instances and their instance classes all stay the same.

The in-place upgrade mechanism involves shutting down your DB cluster while the operation takes place. Aurora performs a clean shutdown and completes outstanding operations such as transaction rollback and undo purge.

関連ドキュメント

docs.aws.amazon.com

in-place upgrades の実践

in-place upgrades を試しに使ってみます.なお,アップグレード前のバージョンは 5.6.mysql_aurora.1.22.2 になります.

f:id:sadayoshi_tada:20210113191843p:plain

Aurora クラスターのバージョン変更

Aurora クラスターのバージョン変更を行います.対象クラスターを選んで 変更 >バージョンのセクションで今回は最新のAurora(MySQL 5.7) 2.09.1 を選択して他のパラメーターをいじらずに次のページに遷移します. f:id:sadayoshi_tada:20210114091211p:plain

変更の確認画面で変更対象の確認をしますが,バージョンアップグレードに伴いクラスターパラメーターグループ,DB パラメーターグループも自動で 5.7 のものに変更になっています.すぐに適用を選択し変更を行います.変更後,少し経つとステータスが アップグレード に遷移します.

f:id:sadayoshi_tada:20210114091504p:plain f:id:sadayoshi_tada:20210114092024p:plain

自分の検証環境では約10分ほどでアップグレードが完了しました.なお,アップグレード後はバックトラックを有効化していてもアップグレード前の時間帯に戻せないとドキュメントに記述があるのでこの点注意です. f:id:sadayoshi_tada:20210114094051p:plain f:id:sadayoshi_tada:20210114102019p:plain

アップグレード中のイベント

イベントメニューよりアップグレード中のイベントを確認することができるので,進行状況を確認したい場合はイベントメニューから参照ください.また,ドキュメントにも記載があるので合わせて確認するよいでしょう.

f:id:sadayoshi_tada:20210114093525p:plain f:id:sadayoshi_tada:20210114093614p:plain

アップグレード前後のバージョン確認

in-place upgrades 実行と合わせてアップグレード前後の MySQL クライアントに接続しバージョンアップグレードの状況を確認してみましたアップグレード実行後に一度 DB コネクションがロストするが,バージョンアップグレード完了後再度クエリを投げるとバージョン情報を返すようになるところを確認できました.

mysql>
mysql> select version(); <= バージョンアップグレード前
+------------+
| version()  |
+------------+
| 5.6.10-log |
+------------+
1 row in set (0.00 sec)
mysql> select version(); <= バージョンアップグレード実行後一時的にコネクションがロスト
ERROR 2013 (HY000): Lost connection to MySQL server during query
mysql>
mysql>
mysql> select version(); <=バージョンアップ完了後再接続
ERROR 2006 (HY000): MySQL server has gone away
No connection. Trying to reconnect...
Connection id:    17
Current database: *** NONE ***
+-----------+
| version() |
+-----------+
| 5.7.12    |
+-----------+
1 row in set (0.02 sec)

まとめ

まずは,Getting Started として Aurora MySQL in-place upgrades 機能を使って MySQL 5.6 から 5.7 にアップグレードしてみました.バージョンが追随できていないし,5.7 使ってみたいと思ってもこれまでのオペレーションだと再度クラスターを作り直す手間があったと思います.,実際の移行の時は計画しっかりし適用箇所を考えなければいけないと思いますが,オペレーションが簡単に行えるのでこの機能は検討して使っていければと考えてます.

AWS Client VPN のユーザー認証を AWS SSO x GSuite で試した

タダです.

前回 AWS Client VPN を SSO と連携したのですが,AWS SSO と GSuite と組み合わせた時にどう動作するのかを確認したくて検証してみます.

検証シナリオ

シナリオとしては,前回 AWS SSO 認証の部分の IdP を GSuite に変えて認証して VPN 接続を試みる以外は変わりません.予め SSO と GSuite の連携を完了していることとします.

f:id:sadayoshi_tada:20210111225340p:plain

関連記事

sadayoshi-tada.hatenablog.com

設定内容

設定内容は前回の SAML 認証設定と変わりません.①AWS SSO のカスタム SAML アプリケーションの登録,属性値の登録,ユーザーの追加,②IAM にカスタム SAML メタデータの登録,③SAML 認証でエンドポイントの再作成および Client VPN 各種再設定です.この点は前回の記事を参照ください.

sadayoshi-tada.hatenablog.com

動作確認

エンドポイントの設定が完了後クライアント設定ファイルをダウンロードして VPN クライアントアプリのプロファイルを追加しました.接続を試みたところGSuite の認証ページに遷移しました.

f:id:sadayoshi_tada:20210111230550p:plain

ユーザー 認証後に VPN 接続が成功しました. f:id:sadayoshi_tada:20210111230644p:plainf:id:sadayoshi_tada:20210111230656p:plain

まとめ

AWS Client VPN のユーザー認証を SSO x GSuite で試してみたので記事にしました.前回の記事からの派生的な内容ですが,GSuite のユーザー認証を使って AWS Client VPN を使えるのを確認できたので,SSO と GSuite を認証で使っているなら利用検討してみてるのは良いかもしれません.

関連記事

sadayoshi-tada.hatenablog.com

sadayoshi-tada.hatenablog.com

sadayoshi-tada.hatenablog.com

Mackerel のホストの変更や監視ルールの操作変更を Slack に通知する

タダです.

Mackerel を触るメンバーが自分以外にもいます.メンバーが自分の知らないところで監視設定を変更したり,Mackerel のホスト変更があった時にそのイベントを知りたいと思って調べた時に,Mackerel のホスト変更や退役,監視ルールの変更といったイベント発生時の通知を有効化し,Slack に通知してみました.どのような通知がされるのかを確認したのでこの記事にまとめていきます.

特定のチャンネルへの通知のイベントを有効化

Mackerel では Slack や Chatwork などの通知のチャンネル設定で次のイベントを通知が可能です.

  • ホストステータス変更
  • ホスト登録
  • ホスト退役
  • 監視ルールの操作

f:id:sadayoshi_tada:20210108002444p:plain

そのため,通知可能な全てのイベントを有効化にして動作を確認してみました.

ホストステータス変更

監視ホストのステータスは Working/Standby/Maintenance/Power Off がありますが,これらのステータスを変更すると以下のように通知されます.一時的なメンテナンス後にちゃんと監視のステータスに戻したかを確認するといった事に活かせそうだと感じます.

f:id:sadayoshi_tada:20210108005423p:plain

f:id:sadayoshi_tada:20210108010459p:plain

ホスト登録・ホスト退役

自分が担当しているシステムでは AutoScaling があるので定期的に Mackerel のホストの登録と退役イベントが発生しているのでそのイベント発生時の通知を確認したところ次のように通知されました.

ホストの登録 f:id:sadayoshi_tada:20210108010356p:plain

ホストの退役 f:id:sadayoshi_tada:20210108074533p:plain

監視ルールの操作

監視ルールを設定したが,誰かが変更したり,新たに追加したりがどのように通知されるのかが気になっていたので個人的に一番気になっていた通知です.画面から監視ルールの新規追加や削除は誰が操作したかの通知がされました.mkrコマンドでも同様に新規追加や削除は通知されました.

管理画面からの監視ルールの新規追加や削除 f:id:sadayoshi_tada:20210108011435p:plain f:id:sadayoshi_tada:20210108011458p:plain

mkr コマンドからの監視ルールの新規追加や削除 f:id:sadayoshi_tada:20210108012142p:plain

確認した範囲では画面もmkrコマンドからの監視ルールの設定変更(CPU 使用率の閾値の変更など)操作イベントは通知されなかったです.こういった用途は Slack をチャンネルに指定するのではなく Webhook 通知を選択するほうが良さそうです.これは別途また確認してみます.

通知チャンネルとして Webhook 通知を選択した場合は、JSON形式の通知内容に監視ルールの変更内容が含まれています。具体的には以下の通りです。

監視ルール作成と更新の場合

mackerel.io

まとめ

Mackerel の通知イベントを Slack に通知してみました.Mackerel の操作イベントも通知してくれるので管理側として知らなかった...といった事態は避けるのをサポートしてくれているなと感じました一部通知されない操作もありましたが,別チャンネルでサポートされているようなので組み合わせて使っていきたいと思います.また他にも通知したいイベントが出てきたらリクエストも出していければと考えています!

通知対象として選べるイベントの種類は、今後も拡張を予定しています。「このイベントも対応してほしい!」といったご意見・ご要望、お待ちしております!

mackerel.io

関連記事

sadayoshi-tada.hatenablog.com

sadayoshi-tada.hatenablog.com

sadayoshi-tada.hatenablog.com

sadayoshi-tada.hatenablog.com

sadayoshi-tada.hatenablog.com

sadayoshi-tada.hatenablog.com

2021年の目標を立てました!

タダです.

あけましておめでとうございます!2020年は大きな変化の年でしたが2021年もよろしくお願いします! 2021年の目標を書いていきます.

2021年の目標

今年の技術的な年間目標として5つを掲げ,このブログでも進捗だったりを発信していきたいと思います.

No. 目標概要 アクション 結果
1 読み手を意識するアウトプット 月間のPV数を平均3,000超えを目指す
はてブの数を気にするより多くの人に見て貰えるブログにする
-
2 AWS認定資格のフルコンプする Alexa Specialityを取ればフルコンプ
4月に SA Pro の更新にも臨む
-
3 GCP認定資格を1つ以上を合格する 業務で GCP にも触れているので理解を深めるために臨む -
4 既存アーキテクチャのリデザインおよび属人化の排除 新しいことをやろうとする時やリソースを足す時に既存アーキテクチャが足かせになっているのでリデザインし,属人的なやり方をしているところを自動化していく -
5 データ基盤の組織内に全体普及する データ基盤を作ったがまだまだ運用課題が多いので組織浸透しきってないため価値を提供できていないところを改善し,課題をクリアして組織内の利用を広げていく -

それ以外の目標

技術的なトピック以外の個人的な目標だったりやるべきことは my-release-noteリポジトリ進捗管理していきます.これまで定期的にやっていることなのに仕組み化できていなかった月次の振り返りやら定期的な自分の棚卸しを GitHub Actions で issue にして振り返るよう仕組み化していくことにしました. my-release-note はもちろん他のことにも取り入れていこうと思います.ナレッジを公開してくださった、よしたくさんと Kawamata Ryo さんありがとうございます!

yoshitaku-jp.hatenablog.com

zenn.dev

まとめ

2021年も変化を恐れず続けてきたものは深化して,新しい刺激を入れていく一年にしていきます!

関連記事

sadayoshi-tada.hatenablog.com

2020年の振り返り

タダです。

2020年も今日で終わりなので,今年の振り返りを行ってきます.

目標の振り返り

まずは,昨年末に立てた目標を振り返ってみます.3つ中2つ達成した状況でした.業務との兼ね合いで来年やっていきたい抱負はまた別記事にまとめます.

No. 目標概要 アクション 結果
1 読み手を意識するアウトプット ホッテントリ入りする記事をを作る(2019年はホッテントリ数が16記事なので20記事を目指す)
月間のPV数を平均3,000超えを目指す
未達
ホッテントリ(新着含む)が15
月間の平均 PV は2874 PV でした.去年より月間3000 PV を超える回数は去年より増やせたのはよかったです.
2 データ分析コンペに1人で参加できるようになる Kaggleのコンペに一人で参戦して1人でモデルや特徴量を作っていけるようになる Kaggler になるのが自分のキャリアでやりたいことではないと思い,アクションから除外した
3 クラウドネィティブなアーキテクチャ設計と実装,運用に関する理解を深める クラウドネイティブなアーキテクチャの設計や運用していくための書籍や講座を通して理解を深める
特にコンテナ技術はクラウドだけでなく,データ分析の文脈でも登場する技術のため理解し扱えるようになりたい
達成
本を読んでブログ書くだけでなく,業務として関わり AWS Copilot のコントリビューションも行えたので去年より関わりが増えました.
4 データベース領域の強化 データベースに対する苦手意識をなくすために資格試験を取り実力を形に残していく 達成
AWS 認定 Database Speciality を取れたので達成としています.

ブログの振り返り

ブログは読み手を意識するアウトプットをテーマにしてきました.去年はブックマーク数が伸びる = PV 数が増えて,見てもらえる記事と思っていたのでブックマーク数と PV 数を気にしていました.ですが,ブックマークがなくても平日1日の平均PV 数が150を超えるようになったのは今年の変わった点です.来年も PV 数は3000以上を目標にして続けていきます.

PV 数
1 2253 pv
2 2259 pv
3 1433 pv
4 2474 pv
5 3484 pv
6 2363 pv
7 3008 pv
8 3391 pv
9 2796 pv
10 3740 pv
11 3279 pv
12 4011 pv(12/30時点)

読者数と Twitter のフォロワー数

読者数と Twitter のフォロワー数の推移も増えているのでいい傾向かと思います.来年も自分を知ってもらって興味持ってもらえる方を増やすようにアウトプットをやっていきます.

読者数 Twitter フォロワー 数
85(34人増) 525(97人増)

その他の振り返り

その他の今年の出来事を振り返っていきます.

技術書典への参加

ずっと憧れていた技術書典に前職の方々と同人誌を出しました.毎回,買うだけだったので日々の学びを同人誌として出して,誰かの役に立ったとかよかったとか言ってもらえる経験ができてよかったです.また出る機会を伺いつつ出せたらいいなと思います.

booth.pm

sadayoshi-tada.hatenablog.com

OSS へのコントリビューション

AWS Copilot のドキュメント修正ですが,コントリュビューションできたのも今年のトピックです.これもずっと憧れていたことで取り組めたので来年も何かしらの形で関わりたいです.

sadayoshi-tada.hatenablog.com

Podcast への出演と自分たちの番組作り

Podcast に呼んでもらったり,自分たちの番組を作るようになりました.Podcast で自分が出る側になるなんて思ってなくて本当に出会いや縁に感謝だなと思います.ラジオのノリというか雰囲気が好きなので今後も続けていければと思います.

呼んでいただいた番組

anchor.fm anchor.fm

自分たちが作っている番組

anchor.fm

転職

そして,転職です.ちょうど今月で入社から3ヶ月経ちました.これまではシステムインテグレーターにいて事業会社でのエンジニアは初となりますが,楽しく仕事させてもらっています.やれていること/やれてないことがあるのですが,直近は負債を返しつつ最低限の守りを固める動きが多いです.新しいことや攻めの取り組みに転じていくためにどんな不安要素があってそれを潰すことで動きやすくなるってのを気にしていたりしてるのですが,その不安要素がなくなれば攻めに転じられると思うので来年は早々に最大の不安要素を取り除いていきたいなと考えています.

www.wantedly.com

sadayoshi-tada.hatenablog.com

まとめ

2020年の一年の振り返りました.今年関わってくれた皆さん本当にありがとうございました,来年もよろしくお願いします!2021年の抱負は次の記事で書いていきます!