『JAWS DAYS 2021 - re:Connect -』でシステムリリースフローの刷新の取り組みを話してきた

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

3/20 開催の「JAWS DAYS 2021 - re:Connect -」にて「スタートアップ企業での散乱したシステムリリースフローをととのえる話」というタイトルでオンライン登壇させていただきました.開発者が安心かつスムーズなリリースフローを作り、開発生産性を向上させたいと言う課題感からリリースフロー刷新に取り組んだお話をしました.この記事で発表を振り返ってきます.

jawsdays2021.jaws-ug.jp

発表資料

発表資料はこちらです.

発表の振り返り

発表した取り組みはリリース周りでまだ仕組み化されてなかったり,複雑になっていることで開発のやりづらさがあるのではないかという課題感や開発サイドへのヒアリングから刷新をしていくことにしました.

改善に向けての取り組みはいくつかの記事でも紹介しておりましたが,GitHub Actions を中心にした形に変えていき,GitHub を見ればリリースに関する設定もわかるし開発者も慣れているツールだから最悪自分がいなくなってもリリースが止まることはないだろうとも思い,採用していきました.また,慣れているからこそ GitHub Actions の処理がうまくいかない時は助言もくれたりしてくれています.

関連記事

sadayoshi-tada.hatenablog.com

sadayoshi-tada.hatenablog.com

sadayoshi-tada.hatenablog.com

システムリリースの部分で課題に感じたところの刷新をしていけたのですが,デプロイしているコードの中にはテストが十分に書けてなかったりしてリリースフローに組み込めてなかったり,発表の中で触れたまとまったコマンドスクリプトがうまくいかない事象が発生し始めたので原因究明して改善していかないといけなかったりと課題が残っているのを潰してよりよい仕組みに育てていければと思います.とはいえ,開発者からはいいリアクションをもらっているのはありがたいことです.

StepFunctionsのSAMデプロイが本番に反映され、開発者から開発しやすくなると言葉もらったのでよき

— Sadayoshi Tada🎉 (@tada_infra) 2021年2月19日

質問への回答

発表に対するツイートで反応くださった方ありがとうございました! 拙い発表においてよかったとリアクションをいただけたりして大変ありがたかったです🙇‍♂️ Twitter で質問いただいていたことについて回答させていただきます.

Q. デプロイのスクリプトがサーバーによって異なるのはなぜか？

デプロイスクリプトがサーバーごとに違うことについて質問いただいていました.ヒアリングの時に判明したのがリリースの対象サーバーにコードを git pull する処理やミドルウェアの再起動などといった処理は共通しているのですが,Rails の db:migrate 処理が1台のサーバーだけで実行するようにしているため特定のサーバーのみは処理が現状異なっています.

サーバーごとにデプロイのコマンドが異なる状態はどういう経緯でそうなったんだろう?
#jawsdays2021_D

— snaka®︎ (@snaka) 2021年3月20日

デプロイスクリプトがサーバーごとに異なるってどういう背景なんだろう#jawsdays2021_D

— longunder (@longunder2) 2021年3月20日

Q. DB は1つなのか？

今後の改善で別れる場合もあるのですが,DB は現状1つです.

ん？
システムが複数あるけどDBは1つしかないのかな・・？#jawsdays2021 #jawsug #jawsdays2021_D

— show (@surumegohan) 2021年3月20日

Q. どのタイミングで GitHub Actions を実行しているのか？

GitHub Actions ですが,EC2 のシステムはプルリクマージ後に指定した時間に Run Command を走らせる設定を定義できるように設定していくようにしています.Lambda/Step Functions は2つのタイミングで走っててプルリクが上がってきたタイミングで差分検出した結果を一時的に S3 に入れるのと,マージ後にデプロイする処理が走っています.

GitHub Actions便利ですよね。どのタイミングでGitHub Actionsを実行していたのかが気になる / 1件のコメント https://t.co/nsbV3baXbx “スタートアップ企業での散乱した システムリリースフローをととのえる話/Maintain the system release flow - Speaker Deck” (1 user) https://t.co/mPibnKk1Ee

— shu1 (@ohsawa0515) 2021年3月21日

まとめ

登壇の振り返りや質問いただいたことを書いてみました.いつもは JAWS DAYS は見るだけな参加を数年続けてきて CFP を出したのは二回目で登壇の機会は初めていただけたので大変ありがたかったです! 登壇者として準備にあたりリハーサルや,配信環境,PR,マイクを送っていただいたりと運営の皆様の手厚いサポートや熱量を非常に感じたイベントでした.また登壇できるように AWS の使い込んで発表していければと思います.ありがとうございました!!

元記事

元記事はこちらです.

最後に

そんなスナックミーではもりもりコードを改善し、開発していきたいバックエンドエンジニア、テックリードを募集中です。 採用の最新情報はこちらにありますので、ご興味ある方はご確認ください！

engineers.snaq.me

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

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

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

mackerel.io

Mackerel を導入した理由

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

labs.snaq.me

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

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

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

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

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

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

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

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

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

まとめ

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

元記事

元記事はこちらです.

最後に

そんなスナックミーではもりもりコードを改善し、開発していきたいバックエンドエンジニア、テックリードを募集中です。 採用の最新情報はこちらにありますので、ご興味ある方はご確認ください！

engineers.snaq.me

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 インスタンスのログイベントを確認します.写真のイベントだとログファイル000118の245880の箇所でバイナリログが切れています.レプリケーションを確認したバイナリログの番号と開始位置から開始していきます.

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

元記事

元記事はこちらです

最後に

そんなスナックミーではもりもりコードを改善し、開発していきたいバックエンドエンジニア、テックリードを募集中です。 採用の最新情報はこちらにありますので、ご興味ある方はご確認ください！

engineers.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 ファミリーを使い慣れておきたく今回使ってみました.定型処理はまとめてしまってメンテナンスウィンドウを活用していきたいと思います.

元記事

元記事はこちらです.

最後に

そんなスナックミーではもりもりコードを改善し、開発していきたいバックエンドエンジニア、テックリードを募集中です。 採用の最新情報はこちらにありますので、ご興味ある方はご確認ください！

engineers.snaq.me

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

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

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

aws.amazon.com

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

sadayoshi-tada.hatenablog.com

Lambda のカスタムランタイムでやっていた処理をコンテナイメージ化して置き換えてみた

— Sadayoshi Tada🎉 (@tada_infra) 2021年1月25日

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

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

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

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 関数をデプロイします.

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

まとめ

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

元記事

元記事はこちらです.

最後に

そんなスナックミーではもりもりコードを改善し、開発していきたいバックエンドエンジニア、テックリードを募集中です。 採用の最新情報はこちらにありますので、ご興味ある方はご確認ください！

engineers.snaq.me

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 が見ているので普段からコミュニケーションを取りやすいものの社内システムチームは会社の構造上アカウント分離していたころフロアが違ったりあんまり接点がなかったのですが,この機会に接点を持ってコミュニケーションを取れるようになりました.この繋がりがあったからステージング使われてないとかじゃあどうする？って話もしやすくなったのを実感したので,他チームとの連携を作るのも今のロール的に不可欠だなぁと痛感しました.

ステージングをつくって開発者に触ってもらったら早速エラーが出ていて期待する動作できてなかったけど一緒にトラシュしててこういうのが欲しかったから環境分けてほんとよかった

— Sadayoshi Tada🎉 (@tada_infra) 2020年12月7日

質問いただいた事

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

G Suite+AWS SSOだとG Suiteのメンバーの同期ができないと思うのですが（SCIM対応してない）、ssosyncを使って同期しているんでしょうか？#JTF2021w_D

— Masa (@maaaato) 2021年1月24日

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

sadayoshi-tada.hatenablog.com

登壇環境

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

まとめ

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

今日のために朝ジムキメたから背景、ダンベルまみれにすれば良かったと後悔しましたw https://t.co/RyxPvWbM85

— Sadayoshi Tada🎉 (@tada_infra) 2021年1月24日

元記事

元記事はこちらです.

最後に

そんなスナックミーではもりもりコードを改善し、開発していきたいバックエンドエンジニア、テックリードを募集中です。 採用の最新情報はこちらにありますので、ご興味ある方はご確認ください！

engineers.snaq.me

胸熱! 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 になります.

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

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

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

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

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

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

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

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

元記事

元記事はこちらです.

最後に

そんなスナックミーではもりもりコードを改善し、開発していきたいバックエンドエンジニア、テックリードを募集中です。 採用の最新情報はこちらにありますので、ご興味ある方はご確認ください！

engineers.snaq.me