こんにちは、プロダクト基盤本部 SREをやっている藤原です。
本エントリは AWS Startup Tech Meetup Online#11 に登壇したのでその報告および内容の解説、補足です。
イベント当日のスライド資料およびアーカイブ動画は下記リンクに掲載されています。
登壇した経緯と所感
自身の経験として前職時代から含めてAWS上で複数のプロダクションサービスを構築してきました。サービス実行の基盤としての利用だけでなくAWS Summitやre:Inforceに参加したりと、エンジニアとしての知識習得といった面でもAWSからの恩恵を受けてきました。
一方でこれまで得た経験や知識をAWSコミュニティに還元できていないことに負い目を感じていました。その中でたまたま@kzk_maedaさんからお声掛けいただき登壇する機会をいただきました。
登壇する中や後には多くのフィードバックや質問をいただきました。いずれのフィードバックもポジティブなものばかりで大変嬉しかったです。いただいた質問もこれまできちんと言語化していなかった部分を改めて言葉に落とし込む良い機会になりました。
どんな話をしたのか
STORES 決済 におけるコンピューティング基盤(Beanstalk on EC2 -> ECS Fargate)の移行事例をテーマに話しました。セッションでは、細かい技術的な詳細よりは各種判断の際の考え方や実際の移行時の流れに重きをおいて解説しています。
登壇内容の解説・補足
当日は、案件固有の前提条件についても軽く触れつつ、判断の軸を解説した上でどうアーキテクチャの切り替えを進めたのかを解説しました。
特に注目してほしいポイントは、
- そもそも論として安全に切り替えるとはどういうことか。
- 安全に切り替える方法にどのようなものがあり、どれを選択したか。
の2点です。
前者は案件の中で定めた目的を達成するまでのリスクをいかにして小さく保つかという話題です。
どこまで切り戻しが可能な状態を維持するか、逆にいうと切り戻し不可能なポイント(PNR, Point of No Return)をどこまで時間的に後ろに倒せるかを重視しました。PNRを可能な限り後ろに倒すことは大規模な構成変更を行う場合においてリスクを小さくする観点で非常に重要です。
後者の安全に切り替える方法は、下図にあげる一般的な3手法から選択しました。
プロダクト固有の制約事項（既存のアーキテクチャ、ミッションクリティカル度合いなど）を考慮して安全側に倒すことを意識しました。結論として、ブルーグリーンデプロイとカナリアデプロイの両方を組み合わせた方法を採用しました。結果、下図に示すような資料中のデプロイ手順になりました。おそらく少々複雑な手順に感じられるでしょう。
確かにパブリッククラウドが提供しているマネージドサービスなどを活用しない場合、大変な困難が伴うであろうことは想像に難くありません。しかし、マネージドサービスの提供する機能を活用することで比較的容易に実現できました。ブルーグリーンデプロイは、CodeDeployのブルーグリーンデプロイ機能や、Elastic Beanstalkのswap url機能を利用して実現しました。カナリアデプロイはALBのリスナールール機能を活用して実現しました。
マネージドサービスの機能を利用する際、とくに利用経験がない場合、"本当に意図したとおり動いてくれるだろうか。安定して動くだろうか。"といった不安が伴うでしょう。しかし、パブリッククラウドサービスは多くの顧客を対象にマネージドサービスを提供しています。自分たちだけでなく同じマネージドサービスを利用している他の人たちも、サービス利用を介して継続的に不具合の検出や改善に結果として協力しています。これらの協力やパブリッククラウドプロバイダ内部の各種改善活動を通じてプロバイダ内には多くのナレッジが蓄積しており、適切な問い合わせを通じてこれらを活用できます。また自分たちがまだ遭遇していない潜在的な問題についても先に利用していた人たちが既に直面した上で改善がなされているといったことも期待できます。
組織内のエンジニアリングリソースが限られている以上、競争優位を作り出せる部分にエンジニアリングリソースを可能な限り投入したいはずです。競争優位につながらないであろう部分についてはマネージドサービスに寄せてしまい、外部の人的、計算機的なリソースに頼ることを第一候補としても良いでしょう。もちろんマネージドサービスのバージョンアップに伴う変更なども必要なので、マネージドサービスのデメリットを認識した上で受け入れることができるかの判断は別途必要です。
使ったことがない不安に拘泥するよりはマネージドサービスを乗りこなす、必要に応じて外部の知恵に頼る気持ちで取り組んだ方がより短期間で目的を達成しつつ、中長期的な運用工数の削減などにもつながるのではないでしょうか。
謝辞
本エントリの元になった登壇の実現には案件そのものの推進がなければありえませんでした。案件の各種作業では STORES 決済のバックエンドチームとQAチームに既存システムの制約事項や事業ドメイン固有の制限などさまざまな面から助言いただきました。チームを横断したやりとりについてはVPoEの佐藤さんに、顧客調整などが必要な部分についてはPdMの永嶋さんに助けていただきました。これらの人たちの協力なくしては案件を無事終えることはできませんでした。本当にありがとうございました。
また、プロダクト基盤本部の仲間も案件の重要性を理解した上で送り出してくれました。大変感謝しています。
おわりに
本エントリや参考スライド、当日のアーカイブ動画をご覧になって掘り下げて訊きたい部分や質問が出てくるかもしれません。その際は、Meety（ウラ凸 - heyのウラ側へ、カジュアル面談で突撃しよう）もやっているので、ぜひお声掛けください。
