SRE チームの藤原です。Tech Kayac Advent Calendar Migration Track 13日目の記事です。
AWS を使っていれば、ほぼ100%なんらかの形で S3 と関わっているでしょう。仮に自分で明示的に S3 にアクセスしなくても、EC2 などのスナップショットは実際には S3 に保存されますし、Aurora も裏ではストリーミングバックアップを S3 に保存し続けていたりします。個人的には、AWS のパワーの根本は S3 の盤石さが支えていればこそ、と思ってもいます。
そんな AWS の最初期から存在する超重要コンポーネントである S3 ですが、2019年6月24日をもって署名バージョン2を廃止するとのアナウンスが2018年末にありました。署名バージョン2を使用しているクライアントは全てアクセスできなくなる、ということでした。
社内での対応
アナウンスを受けて、社内の技術基盤チームでも全社横断で S3 へアクセスしている箇所を確認し、クライアントのバージョンアップを進めました。数年前からアップデートしていなかった aws-cli や fluent-plugin-s3 などが主な対象でしたが、それ以外にも S3 にアクセスするところは多岐にわたり、まあそこそこ大騒ぎしたのは記憶に新しいところです。
社内では他にも、古い SDK を使っていた自作の画像変換サーバーを、画像変換マネージドサービスの ImageFlux と CloudFront + Lambda@Edge で置き換えたりと、この件をきっかけにマイグレーションが進んだりしました。
自作OSSの対応
そして、ここのところいじってないのですっかり忘れていた自作の OSS デプロイツール Stretcher についても対応が必要でした。
Twitter でこんな話を見かけ(エゴサしているので…)
AWS S3 の署名バージョン 2 の廃止の件、デプロイで使っているstretcher大丈夫かなと思って調べてて、コード読むと使っているライブラリが公式SDKではなくV2Signature使っているので対応が必要そう。 https://github.com/AdRoll/goamz/blob/master/s3/s3.go#L99 …
Issue をもらったのでいそいそと対応をしました。ありがたいことです。
なんで忘れていたのかというと、Go の場合は公式の SDK である aws-sdk-go を使用している場合は、最初から Signature V4 なので対応不要だったからです。しかし、Stretcher は公式 SDK がリリースされるより前の 2014 年に開発をはじめた関係で AdRoll/goamz というライブラリを使っていて、この S3 クライアントが Signature V2 を使用していたのでした。
SDK を公式のものに切り替えるついでに、この際なのでバージョンも v1.0.0 としてリリースしました。
ありがとう AdRoll/goamz
現在の公式 SDK は非常に対応が早く、新機能がリリースされた時点でほぼ SDK にも対応が入るという素早さです。re:Invent 2019 の期間中は 2019-12-02 〜 2019-12-05 まで毎日(どころか日に2回も)リリースされるほどで、話題の新機能をすぐに試すことができます。大変ありがたい存在です。
公式 SDK 以前に AdRoll/goamz という使いやすいライブラリがあったことが、自分が Go で AWS 関連ツールを書く力になったのは間違いないところです。最近は役目を終えたのでしょう、3年近く更新もないですが、ここで感謝の意を表したいと思います。
Signature V2 廃止自体は…
ところで、すったもんだのあげく、既存 S3 バケットの Signature V2 廃止は延期になりました。さすがにアナウンスから半年で、世界中で動いている全てのクライアントをバージョンアップするのは不可能だった、ということでしょうか。
とはいえ今後も同様のことはあるでしょう。その時になるべく慌てず、速やかに対応できる態勢を作っておきたいですね。