awsこんにちは、ソーシャルゲーム事業部ゲーム技研チームの谷脇です。今日は一石n鳥の話、もしくは桶屋が儲かる話をします。Trackの2日目の記事です。1日目はMongoDBであるメリットが無くなってしまったのでMySQLに移行したはなしでした。Fargate(以下Fargate)に持っていきました背景ゲーム技研チームではソーシャルゲーム事業部内で使われる開発に便利なグッズを作ったり、運用が必要であれば運用を行うことをやっています。OTAツール、alphawingもその一つです。自動ビルドされる開発版アプリのアップローダとしての機能、スマートフォンから閲覧してダウンロード及びインストールをする機能を持ったWebアプリです。ECSを使っています。細かい生活の知恵グッズを多数運用するときにもこういった本番コンテナサービスは便利です。CVE-2019-5736以下の記事が詳しいです。OSS脆弱性ブログ要約すると、Dockerなどで使われるコンテナランタイムruncにホスト側rootでコマンド実行出来る脆弱性です。簡単に特権昇格できる脆弱性なのでさっさと対応してしまいたいところです。ゲーム技研チームで対応を検討し始めました。terraform管理していたはずだがtfstateが失われたので...alphawing自体は2015年頃から運用されているアプリケーションです。私も2代目ぐらいの開発担当者で、開発当初の状況はあまり知りません。いえ、昨年にアプリケーションコードを全面的に書き直して移行も成功したため、大体の構成の把握はできていると自負していました。それが間違いだったのですが。runc脆弱性対応を行う手法としてまず検討したのは、正攻法ですが、コンテナインスタンスのAMIを脆弱性対応済みのものに入れ替える手法です。社内で動き続けているサービスの性として、できるだけ停止時間を短くする必要もあります。そこで、別のコンテナインスタンスを新しく立ててECSクラスタに入れた上で、新しいインスタンスの方にコンテナを立てた上で、古いインスタンスを停止という方向に持っていく算段でした。terraformという文字列を見つけるterraformで使う状態管理ファイル.tfstateを探すがS3のバケットにもGitHubのリポジトリにもないというわけで、インフラの管理方法は失われてしまっていたようです。新しいAMIを起動するだけのはずなので、おそらくterraformも簡単に作り直せるはずです。そっちにいくのではなく...と、SREチームの組長に背中を押されてFargateに切り替えるぞとなりました。Fargateがある今、このサービスでEC2を使うECS構成を作るメリットが見出だせなかったことがあります。ECSとFargateの違い次のスライドの始めの方に詳しいことが図解されています。#AWSDevDayECSを使う場合は、ECSのコンテナの管理の他にEC2インスタンスの管理も必要です。EC2インスタンスの管理の中には今回のような脆弱性対応も含まれます。Fargateを使う場合は、EC2インスタンスに当たるような実行環境は使う側からは見えなくなり、AWSの管理に委ねられます。いわゆるフルマネージドサービスと呼ばれるものです。AWSが行う「管理」とは、脆弱性に対応するためのパッチ当ても含まれます。その違いを、今回の脆弱性に対応する人向けにAWSから出された文章から抜き出してみます。AMI.ECSの場合は使っているAMIを入れ替えてねと書かれています。Fargateの場合は、aws-cliで--force-new-deploymentをつけてserviceを更新すれば、勝手にアップデートされるよと書かれています。alphawingであればecspressoを使っているので、単にデプロイを行えば同じような効果が得られます。いうわけで、ある程度マネージドなサービス(ECS)と、フルマネージドサービス(Fargate)の違いが実感できます。今回の脆弱性と同じようなことがあっても、Fargateに移行しておけば簡単に対応できることが期待できます。移行作業ecspressoを使用していたので、ecspressoで使う設定用JSON書き換えと、ALBからの向き先入れ替えが主な作業になります。Fargateが動く新しいECSのServiceを作って並列動作させた上で、古いServiceを停止して無停止で移行できました。作業を始めてからだいたい2時間ぐらいで移行が完了しました。までアップグレードするついでにECS化した話」です。バージョン番号が8倍になる話をするそうです。2019の2日目の記事です。