snaqme Engineers Blog

おやつ体験BOX snaq.me エンジニアによる開発プロダクトブログ

Mackerel アンバサダーの一員になりました!

こんにちは!SRE を担当している多田です(@tada_infra).

この度 Mackerel アンバサダープログラムに招待いただき,アンバサダーの一員に加えていただくことになりました! Mackerel は業務で導入することになったことがきっかけで使い始めたのですが,アンバサダープランも適用いただいたので普段使えてない機能などますます活用していければと思っております.

f:id:sadayoshi_tada:20210314213527p:plain

mackerel.io

Mackerel を導入した理由

Mackerel を導入したのは冒頭に書いた通りで業務上監視が行き届いてない部分を潰したいという課題感から他の監視系 SaaS を比較検討して導入しています.導入前や導入以降の話は下記の記事に書いているので見てもらえると嬉しいです.

labs.snaq.me

上記の記事に書けてなかったことで自分がいくつかの監視 SaaS から Mackerel を上司に推した理由を書いてなかったので書いていきたいと思います.監視のサービスの中でも導入検討時に以下の点を上司にも推していました.

  • 日本語のサポートを受けられること
  • 監視ができてなかったシステムの必要な監視を賄えること
  • エージェントを仕込めばすぐに監視始められること
  • コスト体系がシンプルかつ試算してみたところ予算内に収まったこと

個人的にサービスを知ってからいいなーと思っていたのが次の2点です.2点目は特に日本生まれだからな部分はありますw

  • 標準提供されている機能だけでなく外部の方が機能開発にコントリュビュートされていて欲しい機能をユーザー側からも作っていること
  • 日本初のサービスだから発展を応援したいこと

ということもあり導入にいたり,本日に至るまで自社の運用を支えてもらっています.今後も Mackerel を活用した最適なオペレーションを模索していきます.

アンバサダーになってやっていきたいこと

アンバサダーになったことで今後やっていきたいことがあります.アンバサダープランを適用をしていただいたので普段使えてない機能を活用するのはもちろんなのですが,自分が Mackerel を本格的に使い始めたのが昨年の10月からになるのでまだまだ機能改善要望を出したりするに至るところまで使い込みができていないと思います.が,そんな日が浅い自分だからこその視点で次のアンバサダーの活動をやっていきたいです.

  • 引き続き Mackerel の記事の執筆
    • 検証結果の記事
    • Mackerel 運用にまつわる記事
  • 使ってみた機能の改善要望などのフィードバックやコントリュビュート

ブログでの発信は今後も続けていきます.ここ最近はできていないのですが,新しく運用に組み込みたい機能の検証もやっているのでまた記事を書いていきます! 自分が憧れている OSS のコントリュビュートにお世話になっている Mackerel でも関われるところあれば関わらせてもらえたらと考えてます.

まとめ

Mackerel アンバサダーの一員になったことと導入背景や今後のやりたいことを書いていきました.自分の発信を見ていただいて選んでいただけたのかなと思いますので,今後もブログ以外のアウトプットを通じて Mackerel の魅力をお伝えしていけたらと思っているので今後もやっていくぞ!💪

元記事

元記事はこちらです.

Aurora のクローン機能を使ったバイナリログレプリケーションを実行してみた

こんにちは!SRE を担当している多田です(@tada_infra).

本番稼働中の Aurora のデータを別の Aurora に移行するために DMS を使おうと思いバイナリログを有効化して DMS の準備をしていました.ただ,DMS のトラブルシューティングを確認してみるとオブジェクトの作成ができないものがあり,ソースデータベース とターゲットデータベースが同一の場合オブジェクトはネイティブツールを使うことが記載がありました.今回のデータ移行も同一 Aurora 間なのでネイティブな機能であるバイナリログレプリケーションで行う方法を使うために設定方法を確認したのでその内容をまとめていきます.

外部キーとセカンダリインデックスが見つからない

AWS DMS は、テーブル、プライマリキー、場合によっては一意のインデックスを作成しますが、効率的にソースからデータを移行するために必要ではない他のオブジェクトは作成されません。たとえば、セカンダリインデックス、非プライマリキーの制約、データデフォルトは作成されません。

データベースからセカンダリオブジェクトを移行するには、ソースデータベースと同じデータベースエンジンに移行中の場合、データベースのネイティブツールを使用します。ソースデータベースで使用したものとは異なるデータベースエンジンに移行してセカンダリオブジェクトを移行する場合は、AWS Schema Conversion Tool (AWS SCT) を使用します。

Aurora 間でのバイナリログレプリケーション

Aurora から Aurora へのバイナリログレプリケーションの方法は下記のドキュメントで紹介されてますが,ドキュメントではスナップショットから復元するパターンです.この記事ではクローン機能を使って確認したのでその内容で整理します.

docs.aws.amazon.com

バイナリログレプリケーションのためにやることは大きく3つです.

  1. クラスターパラメーターグループのbinlog_formatのパラメーターをMIXEDに変更
  2. レプリケーション元の Aurora でレプリケーション用ユーザーとバイナリログ保存期間を設定
  3. Aurora をクローンしてクローンしたクラスターでレプリケーションを実行

1.クラスターパラメーターグループのbinlog_formatのパラメーターをMIXEDに変更

Aurora クラスターパラメーターグループのbinlog_formatのパラーメーターをMIXEDに変更します.バイナリログの有効化のために WRITER 側のインスタンスを再起動します.再起動後,バイナリログの記録ファイルが出る状態になっていることを確認します.

mysql> show global variables like 'log_bin';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| log_bin       | ON    |
+---------------+-------+
1 row in set (0.01 sec)
mysql> show variables like 'binlog_format';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| binlog_format | MIXED |
+---------------+-------+
1 row in set (0.00 sec)
mysql> show binary logs;
+----------------------------+-----------+
| Log_name                   | File_size |
+----------------------------+-----------+
| mysql-bin-changelog.000001 |       120 |
| mysql-bin-changelog.000002 |     43424 |
+----------------------------+-----------+
2 rows in set (0.00 sec)

2. レプリケーション元の Aurora でレプリケーション用ユーザーとバイナリログ保存期間を設定

次にレプリケーション元の Aurora でレプリケーション用ユーザーとバイナリログ保存期間を設定します.まずレプリケーションユーザーですが,今回ドキュメント記載の repl_user と権限で作っています.

mysql> CREATE USER 'repl_user'@'%' IDENTIFIED BY '<パスワード>';
Query OK, 0 rows affected (0.01 sec)
mysql> GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'%' IDENTIFIED BY '<パスワード>'
Query OK, 0 rows affected (0.01 sec)

ユーザー作成後,レプリケーションが終わるまでのログの保存期間を設定するため,バイナリログ保存期間を指定します.確認した限りですが,ドキュメント記載の最大値は 2,160 (90 日)はエラーが出て利用者側で指定できるのは168(7日間)までのようなのでこの値で指定します.なお,最大値の期間を指定するためには AWS サポートへの問合せが必要になることが AWS サポートへの問合せで教えていただきました.

mysql> CALL mysql.rds_set_configuration('binlog retention hours', 168);
Query OK, 0 rows affected (0.02 sec)

3. Aurora をクローンしてクローンしたクラスターでレプリケーションを実行

準備ができたのでレプリケーション先の Aurora クラスターをクローン機能で複製します.復元したクラスターの WRITER インスタンスのログイベントを確認します.写真のイベントだとログファイル000118245880の箇所でバイナリログが切れています.レプリケーションを確認したバイナリログの番号と開始位置から開始していきます. f:id:sadayoshi_tada:20210313195906p:plain

mysql> CALL mysql.rds_set_external_master ('<レプリケーション元の Aurora WRITER エンドポイント>', 3306, 'repl_user', '<パスワード>', 'mysql-bin-changelog.000118', 245880, 0);`
Query OK, 0 rows affected (0.19 sec)
mysql> CALL mysql.rds_start_replication;
+-------------------------+
| Message                 |
+-------------------------+
| Slave running normally. |
+-------------------------+
1 row in set (1.02 sec)

SHOW SLAVE STAUS でチェックしてSeconds_Behind_Masterが0になるまでいきます.自分が検証したエラーとしてレコード重複のメッセージがでてきて無視していいものはCALL mysql.rds_skip_repl_error;でスキップしたり,外部キー制約で同期できなかったレコードはSET FOREIGN_KEY_CHECKS = 0を無効化して同期していきました.

mysql> SHOW SLAVE STATUS\G;
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: xxxx.ap-northeast-1.rds.amazonaws.com
                  Master_User: repl_user
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin-changelog.000118

~中略~
              Seconds_Behind_Master: 0
~中略~
1 row in set (0.00 sec)

まとめ

Aurora クラスター間のバイナリログレプリケーションを行う方法をクローン機能使った場合で整理してみました.個人的にクローンを初めて使ったのですが,高速に復元できてすぐにレプリケーションを走らせられたのがとても良い体験でした.今後こういったレプリケーションは Aurora のバージョンアップの時にも使っていけるかと思ったのでその時は適宜使っていきます.

docs.aws.amazon.com

関連記事

labs.snaq.me

元記事

元記事はこちらです

SSM Run Command をメンテナンスウィンドウで実行する

こんにちは!SRE を担当している多田です(@tada_infra).

業務の中で日時を決めて SSM Run Command を実行したい要件がでてきたのでメンテナンスウィンドウを使ってみることにしました.この記事ではメンテナンスウィンドウを AWS CLI を使って設定して行ったメモを備忘録として書いていきます.

メンテナンスウィンドウとは

メンテナンスウィンドウは Systems Manager 関連のサービスで期間や日時を指定したりしてタスクを実行することができます.サポートされているタスクタイプは次の4つです.

  • Systems Manager Run Command コマンド
  • Systems Manager オートメーションワークフロー
  • AWS Lambda 関数
  • AWS Step Functions タスク

docs.aws.amazon.com

AWS CLI での設定コマンド

1. メンテナンスウィンドウの作成

メンテナンスウィンドウは create-maintenance-window で作っていきます.レスポンスで返ってきているWindowsIdがメンテナンスウィンドウを識別する ID です.2時間の間5分毎にタスクを実行するメンテナンスウィンドウになっています.

aws ssm create-maintenance-window \
    --name "test-maintenance-window" \
    --schedule "rate(5 minutes)" \
    --duration 2 \
    --cutoff 1 \
    --allow-unassociated-targets
{
    "WindowId": "mw-xxxx"
}

2. メンテナンスウィンドウでターゲットの登録

メンテナンスウィンドウのタスク実行先(ターゲット)を設定していくには register-target-with-maintenance-window を使います.EC2 に対してコマンドを実行したいのでそのようなパラメータになっています.

aws ssm register-target-with-maintenance-window \
    --window-id "mw-xxxx" \
    --resource-type "INSTANCE" \
    --target "Key=InstanceIds,Values=i-xxx"
{
    "WindowTargetId": "xxxx-xxxx-xxxx-xxxx-xxxx"
}

3. ターゲットに対して実行するタスクの登録

メンテナンスウィンドウとターゲットの登録が完了したので,ターゲットに実行したいタスクを登録していきます.Run Command を登録したいので register-task-with-maintenance-window を使って登録します.lsコマンドを実行するだけのタスクを登録しました.

aws ssm register-task-with-maintenance-window \
    --window-id mw-xxx \
    --task-arn "AWS-RunShellScript" \
    --max-concurrency 1 --max-errors 1 \
    --priority 10 \
    --targets "Key=InstanceIds,Values=i-xxxx" \
    --task-type "RUN_COMMAND" \
    --task-invocation-parameters '{"RunCommand":{"Parameters":{"commands":["ls"]}}}'
{
    "WindowTaskId": "xxxx-xxxx-xxxx-xxxx-xxxx"
}

タスクの実行状況はdescribe-maintenance-window-executionsで確認できます.確認したみたところ,SUCCESSステータスになっているので問題なさそうです.

aws ssm describe-maintenance-window-executions \
    --window-id mw-xxxx
{
    "WindowExecutions": [
        {
            "WindowId": "mw-xxxx",
            "WindowExecutionId": "xxxx-xxxx-xxxx-xxxx-xxxx",
            "Status": "SUCCESS",
            "StartTime": "2021-03-07T22:52:36.863000+09:00",
            "EndTime": "2021-03-07T22:52:43.710000+09:00"
        },
        {
            "WindowId": "mw-xxxx",
            "WindowExecutionId": "xxxx-xxxx-xxxx-xxxx-xxxx",
            "Status": "SUCCESS",
            "StatusDetails": "No tasks to execute.",
            "StartTime": "2021-03-07T22:47:36.990000+09:00",
            "EndTime": "2021-03-07T22:47:37.026000+09:00"
        },
        {
            "WindowId": "mw-xxxx",
            "WindowExecutionId": "xxxx-xxxx-xxxx-xxxx-xxxx",
            "Status": "SUCCESS",
            "StatusDetails": "No tasks to execute.",
            "StartTime": "2021-03-07T22:42:36.936000+09:00",
            "EndTime": "2021-03-07T22:42:36.969000+09:00"
        },
        {
            "WindowId": "mw-xxxx",
            "WindowExecutionId": "xxxx-xxxx-xxxx-xxxx-xxxx",
            "Status": "SUCCESS",
            "StatusDetails": "No tasks to execute.",
            "StartTime": "2021-03-07T22:37:36.723000+09:00",
            "EndTime": "2021-03-07T22:37:36.758000+09:00"
        }
    ]
}

4. メンテナンスウィンドウの時間を更新する

このままだと5分に一回コマンドが実行され続けるので時間部分を更新しておきます.今回は一度だけ実行したいメンテナンスウィンドウに更新したいのでat(UTC時間)で日時を指定してみます.メンテナンスウィンドウを更新するには update-maintenance-windowを使います.日本時間の2021/03/07 23:00の日時を指定しています.

aws ssm update-maintenance-window \
    --window-id mw-xxxx \
    --schedule "at(2021-03-07T14:00:00)"
{
    "WindowId": "mw-xxxx",
    "Name": "test-maintenance-window",
    "Schedule": "at(2021-03-07T14:00:00)",
    "Duration": 2,
    "Cutoff": 1,
    "AllowUnassociatedTargets": true,
    "Enabled": true
}

実行状況を確認してみます.23時にタスクが実行されていました.

 aws ssm describe-maintenance-window-executions \
    --window-id mw-xxxx
{
    "WindowExecutions": [
        {
            "WindowId": "mw-xxxx",
            "WindowExecutionId": "xxxx-xxxx-xxxx-xxxx-xxxx",
            "Status": "SUCCESS",
            "StartTime": "2021-03-07T23:00:17.287000+09:00",
            "EndTime": "2021-03-07T23:00:23.046000+09:00"
        },
        {
            "WindowId": "mw-xxx",
            "WindowExecutionId": xxxx-xxxx-xxxx-xxxx-xxxx",
            "Status": "SUCCESS",
            "StartTime": "2021-03-07T22:57:36.885000+09:00",
            "EndTime": "2021-03-07T22:57:42.674000+09:00"
        },

まとめ

AWS CLI を使ってメンテナンスウィンドウを登録して Run Command を実行できるようにしてみました.Systems Manager の活用を進めており,Run Command や処理をまとめた Document,Automation を使うため Systems Manager ファミリーを使い慣れておきたく今回使ってみました.定型処理はまとめてしまってメンテナンスウィンドウを活用していきたいと思います.

元記事

元記事はこちらです.

カスタムランタイム の Lambda をコンテナイメージ化してみた

こんにちは!SRE を担当している多田です(@tada_infra).

Lambda のアップデートで昨年の re:Invent でコンテナがサポートされました.

aws.amazon.com

自前のコンテナイメージを実行できるならカスタムランタイムで設定している Lambda の処理をコンテナイメージ化してみようと思い,下記の記事でカスタムランタイムで実行していた Lambda をコンテナイメージ化して変更してみました.この記事で対応内容を書いていきます.

sadayoshi-tada.hatenablog.com

コンテナサポート対応設定

実行環境のコンテナは ECR に格納する必要があり,これまでとの違いは Dokcerfile を用意する必要がある点です.AWS から Lambda のコンテナイメージが提供されており,そのイメージを使っていきます.

サポートされているすべての Lambda ランタイム (Python、Node.js、Java、.NET、Go、Ruby) のベースイメージを提供しているため、コードと依存関係を簡単に追加することができます。Amazon Linux ベースのカスタムランタイム用のベースイメージも用意しており、これを拡張して Lambda ランタイム API を実装する独自のランタイムを含めることができます。

f:id:sadayoshi_tada:20210127081551p:plain gallery.ecr.aws

ECR に格納する Dockerfile を次のように定義しました.AWS CLI を使った処理を行ったので AWS CLI を入れて,カスタムランタイムで使っていた bootstrap とカスタムランタイムの関数内で書いていたロジックをスクリプト化して実行するようにしました.

Dockerfile

FROM public.ecr.aws/lambda/provided:latest
RUN yum install -y awscli
COPY bootstrap /var/runtime/bootstrap
COPY xxx.sh /var/runtime/xxx.sh
RUN chmod 755 /var/runtime/bootstrap /var/runtime/xxx.sh
CMD ["xxx.handler"]

bootstrap

#!/bin/sh
set -euo pipefail
# Initialization - load function handler
source $LAMBDA_TASK_ROOT/"$(echo $_HANDLER | cut -d. -f1).sh"
# Processing
while true
do
  HEADERS="$(mktemp)"
  # Get an event. The HTTP request will block until one is received
  EVENT_DATA=$(curl -sS -LD "$HEADERS" -X GET "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/invocation/next")
  # Extract request ID by scraping response headers received above
  REQUEST_ID=$(grep -Fi Lambda-Runtime-Aws-Request-Id "$HEADERS" | tr -d '[:space:]' | cut -d: -f2)
  # Run the handler function from the script
  RESPONSE=$($(echo "$_HANDLER" | cut -d. -f2) "$EVENT_DATA")
  # Send the response
  curl -X POST "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/invocation/$REQUEST_ID/response"  -d "$RESPONSE"
done

ECR にコンテナイメージをプッシュする

コンテナイメージを ECR に格納していきます.ECR で表示するコマンドを順次実行していきます.

# ECR ログイン
aws ecr get-login-password --region ap-northeast-1 | docker login --username AWS --password-stdin xxx.dkr.ecr.ap-northeast-1.amazonaws.com
# Dockerfile のビルド
docker build -t xxx .
# タグつけ
docker tag xxx:latest xxx.dkr.ecr.ap-northeast-1.amazonaws.com/xxx:latest
# イメージのプッシュ
docker push xxx.dkr.ecr.ap-northeast-1.amazonaws.com/xxx:latest

Lambda 関数の設定

ECR にコンテナイメージを格納できたら Lambda 関数を作っていきます.これまでの差異は関数作成時にコンテナイメージを選択することです.前の工程でプッシュしたイメージのlatestバージョンを選択して,他の設定を行って Lambda 関数をデプロイします.

f:id:sadayoshi_tada:20210129004551p:plain f:id:sadayoshi_tada:20210129004640p:plain

デプロイ後のコード部分を見に行くとコンテナイメージがデプロイされているからコードは見えない仕様になっています.イベント発火後の処理をコンテナ内で設定しておけばこれまで通りカスタムランタイムの Lambda で実行していたのと同様の処理を実行できました.

f:id:sadayoshi_tada:20210129004856p:plain

まとめ

カスタムランタイムの Lambda をコンテナイメージに置き換えたのでその対応をまとめました.カスタムランタイムの Lambda をデプロイするのに Lambda Layer の設定が必要でコードの他にも管理するものがありましたが,コンテナイメージをメンテするだけで同じことができるようになったのは管理範囲が狭まりました.開発時にコンテナイメージを使って開発しているのであれば,開発・デプロイがしやすいのかと思いました.自社でも普及していきたいと思います.

元記事

元記事はこちらです.

JTF2021w で『スタートアップ企業でのAWS マルチアカウント運用の実践と普及』と題して#推しテクを発表した

こんにちは!SRE を担当している多田です(@tada_infra).

1/24 開催の「July Tech Festa 2021 winter #推しテク総選挙」にて「スタートアップ企業でのAWS マルチアカウント運用の実践と普及」という AWS 管理をしていくなかでアカウントを分割し,組織に分離したアカウントを使ってもらえるよう浸透させていく取り組みをお話ししました.この記事で発表を振り返ってきます.

techfesta.connpass.com

発表資料

発表資料はこちらです.

当日の発表は後日 YouTubeアーカイブされるので他のセッションも見えてなくて残念...と思っている方は是非登録することをオススメします. www.youtube.com

他のセッションの発表資料も connpass の資料一覧から見ることができます.

techfesta.connpass.com

発表の振り返り

発表は以前の JAWS-UG 朝会で発表していたものをアップデートした内容なんですが,当時はマルチアカウント化しはじめた頃でとりあえずステージング出来たくらいのタイミングでした.その頃からステージングが使われず,普及のために動き出したことがアップデートとして話せたと思います.

sadayoshi-tada.hatenablog.com

発表で言えてなかったこととして,課題に感じたアーキテクチャの変更が1アカウントのままだとやり辛いことの中でシステム全体も含んでいたのですが,デプロイ周りも今自動化できているものもあれば手動デプロイしているものもあります.手動デプロイをなくすための検証もし辛いなと思っていたので環境を分離したかった感じです.

あと,副次的な効果ですが,ステージングをつくったりして環境を分離したことでよかったのが開発チームとの密な連携が取れている気がします.うちは社内システムと外向けシステムで大きく分かれているんですが,外向けは CTO が見ているので普段からコミュニケーションを取りやすいものの社内システムチームは会社の構造上アカウント分離していたころフロアが違ったりあんまり接点がなかったのですが,この機会に接点を持ってコミュニケーションを取れるようになりました.この繋がりがあったからステージング使われてないとかじゃあどうする?って話もしやすくなったのを実感したので,他チームとの連携を作るのも今のロール的に不可欠だなぁと痛感しました.

質問いただいた事

Masa さんから ssosync を使って運用しているのかという質問をいただきました.今のところ使ってなくても ID が同期されないといったトラブルに見舞われていないので使っていないのですが,ssosync の存在を知らなかったのでこの機会に試して適用を検討させていただきます.教えていただきありがとうございました🙇‍♂️

Tamakiさんからどうして SSO を絶対やりたいというツイートしたのかって質問をもらったのですが,緊張してうまく答え切れていなかったので改めて回答させてもらいます.前職でシングルサインオンのサービスを使っていてシングルサインオンの便利さやメリットを実感できていたからこそパスワードの強度や管理が人依存になっている自社では絶対パスワード認証ログインを辞めたいと思ったから SSO を入れたかったのです.

sadayoshi-tada.hatenablog.com

登壇環境

登壇環境については非常にかっこいい感じにしたかったのですが,全然映えはないですw 他の方も見てみたい...

f:id:sadayoshi_tada:20210125094448p:plain

まとめ

登壇の振り返りや質問いただいたことを書いてみました.オンラインイベントなので喋る時はもちろん1人ですが,ツイートを追ったりして反応をくださっているのほんとうにありがたかったし,内容も良いという反応があると嬉しすぎてニヤけますね...いつも見る側の立場だったので登壇させてもらえて貴重な機会をいただき本当にありがとうございます.その辺の気持ちはこのツイートにしたためました.心残りとしては Zoom ならではの発表なのに背景をダンベルまみれにしなかったことくらいですが,運営の皆さん,登壇者の皆さん,聞いてくださった皆さんとても暖かく接してくださって登壇者としても楽しくイベント参加できました! これはオフラインとしてもイベントが実現された時にも登壇できるよう日々の取り組みをやってこうと思います.改めてありがとうございました!!

元記事

元記事はこちらです.

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

あけましておめでとうございます! SRE を担当している多田です(@tada_infra).

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 使ってみたいと思ってもこれまでのオペレーションだと再度クラスターを作り直す手間があったと思います.,実際の移行の時は計画しっかりし適用箇所を考えなければいけないと思いますが,オペレーションが簡単に行えるのでこの機能は検討して使っていければと考えてます.

元記事

元記事はこちらです.

2020年終わりに

こんにちは スナックミー CTOの三好です @miyoshihayato 先月にスタートした弊社の技術ブログですが、まだ私は書いてなく、最低1本今年中に書きたかったので書きます。

スナックミーはどういうサービスでエンジニアの関わり方どうなっているのか長くなりすぎず書いていきます。 時間がない方は↓↓をざっとでもいいのでご覧ください

※ 適時スライドはアップデートしていきます

おやつ体験 snaq.me

snaq.meの概要を説明させてください。

f:id:snaqme-labs:20201228194557p:plain
スナックミーの概要

snaq.meがお届けするのは、お菓子という単なる「モノ」ではなく、おやつ時間、そしてワクワクしたり楽しんだりする体験、つまり『おやつ体験』です。 "毎月変わる100種以上のおやつ"から、食べきりサイズ(約20-30g)で8つお届けします。全てのおやつが人工添加物、ショートニング、白砂糖など不使用。ナチュラル素材のみからできているのが特徴です。 ジャンルはクッキー・パウンドケーキといった焼き菓子からドライフルーツ・ナッツ・米菓、羊羹・どら焼きなどの和菓子まで幅広く取り扱っています。

あらゆる声を大事にする

お客さまとのやり取りはLINEをサービス開始当初から導入しています。LINEを用いることでメールとは違い気さくに連絡をいただける方が多く、ポジティブや厳しいことなどさまざまなお声いただきます。そのような声を社内全体に共有するチャンネルが存在し、共有することでチャンネルが活性化し様々な声から施策が生まれることが多々あります。そのため、直接お客さまと関わらないのメンバーでも距離は近く感じられます。

データの活用

お客さまには届いた後におやつの評価や次回以降これを食べたいことを主張できるリクエストなどアクションをとってもらうことが可能で f:id:snaqme-labs:20201228202315p:plain お客さまの声や評価・リクエストのデータを用いて商品開発や次回お届けするおやつを決定しています。

製造から発送準備まで一貫

弊社特徴の一つなのが、このロジスティックス周り

  • 製造から発送準備までを内製化

  • 同じビル内で製造や出荷作業(ピッキング)

f:id:snaqme-labs:20201228205522p:plain 内製化し同じビル内で作業をしているので、どのようにおやつがパックされ、出荷(箱詰め)されてお客さまの手元に届くのかというこの流れを肌で感じることができます。 エンジニアは開発したシステムを利用する相手の顔が見えにくいですが、スナックミーではリアルなモノの流れを体験できます。

エンジニアとチームの関わり方

エンジニア限らずスナックミー全体は様々なチームと連携しながら事業を展開しています。 f:id:snaqme-labs:20201229210256p:plain

体験

snaq.meの購入前から購入後のマイページまで、ユーザーの”おやつ体験”に関わる様々な部分の構築を行なっています。 購入導線やおやつの好みの診断、評価・リクエストなどのページがあります。A/Bテストを通して各ページの改善や、データサイエンティストやデザイナーと共にUI/UXの向上などユーザーの体験向上を目指しています。 スナックミー全社員「永遠のβ版」という概念を持っており、お客様のフィードバックを活用しサービス改善を続けていき、製菓業界の枠組みにとらわれない挑戦を続けてまいります。

体験チームインタビューはこちら↓↓

おやつのテーマパークを一緒に作りませんか?

商品開発

今まで数千という商品を扱いユーザーの構成や行動、今までの商品に対する評価や味覚、食感の好み、リクエスト数、アンケートなどから得た知見をバイヤーやパティシエに共有し、多角的に話合いながら、新しいおやつの開発に役立てています。

商品開発チームインタビューはこちら↓↓

ほっこりおやつタイムを豊かにするデータ分析

オペレーション (ロジスティックス)

製造管理・出荷管理のソフトウェアの部分は弊社で開発しています。 例えば出荷作業に関しては、音声ピッキングを導入し、出荷効率を5~10倍アップさせることができました。 スナックミーの特徴として、

  • 毎月取り扱うおやつを数十%入れ替え (新商品含む)

  • 製造方法が異なる

  • 少量多種 (少ない量で多くの種類を製造)

などです。製造ラインは1種類1つがよくある中、スナックミーでは製造方法が異なり毎日数十種類存在する条件でもスケールできるオペレーション構築を目指していきたいと思っています。

f:id:snaqme-labs:20201229212405p:plain
出荷スペース

オペレーションチームインタビューはこちら↓↓

おやつを届けるオペレーションとエンジニアリング

CS

CSチームで考えることは

  1. 問い合わせを発生しない環境

  2. エンゲージメントを高める

この2つにあり、問い合わせを発生させない環境づくりは基本としてあるものの、エンゲージメントを高めることも意識的に行っています。 問い合わせが来るものだけを対応せず、私たちから連絡を取っていくようにしています。例えば評価内容から苦手な評価を多くつけている方には好き嫌いがないか確認し次回のボックスに活かすようにしています。

カスタマーサービスチームインタビューはこちら↓↓

様々な声を全体に浸透させていきたい

技術スタック

f:id:snaqme-labs:20201230184709j:plain

PHPからPythonへ移行中

フロントはReact × Redux、ロジスティックスはRails、基盤は AWS (一部GCP)でスナックミーを支え、開発手法はスクラムになっています。

最後に

2020年1月はエンジニアは4名だったメンバーが、2021年1月からエンジニアは8名(育休含む)に心強いメンバー増えます。 ここ1年で人数は倍になりスナックミーとしてできることが多くなってきました。しかし、成し遂げたいことは多くありメンバーは足りていません。一緒にブランドを構築し、技術力もアップしませんか? 少しでも興味もった方は気軽に連絡お待ちしております。

2021年は更なる飛躍の年に!! 外部発信も来年は精力的にやっていきます

engineers.snaq.me

www.wantedly.com