AWS Proton with ECS のハンズオン手順書を日本語化しました
イベントばかりでブログを全然書けてなかった。久しぶりの投稿です。 AWS Proton のハンズオン手順書を日本語化しましたのでブログにも残しておきます。
AWS Proton とは
開発エンジニアとインフラエンジニアのロールの違いは、責任をもつリソースにも反映されます。その１つとしてインフラの構成を再現するための CloudFormation、Terraform などのインフラの状態を宣言するためのコード群があります。 そして、作られたコードは開発エンジニアがアプリケーションを実行するインフラをタイムリーに構築するためや、プロダクション環境にデプロイするために使われます。
後者のデプロイについてはインフラエンジニア、開発エンジニアがリリースに向けたチームを構成し、適用することがほとんだと思いますが、前者の開発エンジニアが欲しい時にタイムリーに環境を用意する場合にはインフラエンジニアが介在しないことが好ましいとされています。
この時、課題となるのが CloudFormation、Terraform などの知識を開発エンジニアにも求められることです。この課題を解消するためのサービスが AWS Proton です。
開発エンジニア、インフラエンジニアは AWS Proton を共通的なインタフェースにすることで、バックグラウンドで実行される CloudFormation や Terraform を意識することとなく必要な時にアプリケーションを実行する環境を用意することが可能となります。
AWS Proton が対象とする環境は コンテナおよびサーバーレスアプリケーション です。
ハンズオン手順について
日本語化した手順書は、こちらのAWS公式サンプルを参考にしています。 github.com
上記のAWS公式サンプルだけでも各ステップを追いながら AWS Proton の動作を確認することは可能ですが、下記の理由からハンズオン手順を日本語化しました。
- ハンズオンを通して作成される構成を図示した形で手順を進めることで１つ１つの手順の意味を明示したかった
- マネージメントコンソールの操作も示しながら AWS Proton の設定とバッググラウンドで動作する CloudFormation などの仕組みも理解できるようにしたかった
- の知識がない方も気軽に試せるようにハンズオンの準備から手順化したかった
- 日本語化することでJAWS-UGのイベントなどで手軽に試せるようにしたかった
単純に日本語化するだけではなく、設定を確認するの手順や、動作の補足説明、作った環境を掃除する手順を追加しています。手順を追加することで私自身の AWS Proton に対する理解を深めることにもなりました。
日本語化した手順はこちらです。 masanoriyamaguchi.github.io
ハンズオンを一通り実行することで下記の構成が作成され、AWS Proton、CodeBuild/CodePipeline、 ECS Fargate の動作も確認することができます。
ハンズオンを一通り実行した場合にかかる費用は数ドルとなっています。
手順で気になるところなどありましたら、こちらのGithubリポジトリよりIssueを作成いただくか、@kinunoriまでメンションを飛ばしてください。
(再掲)CodeDeployでEC2へデプロイした結果、処理が1つも進まずに失敗してしまうときの対処方法
私はインフラエンジニアとして開発案件に関わることがありますが、開発チームが開発速度を落とさずに最短で価値提供ができるようにインフラから支えることを気をつけています。
インフラはプラットフォームの1つであり、価値提供を行うものはアプリケーションです。アプリケーションが安定してサービスの価値を提供できること、新しい価値を提供できるまでの速度を落とさないことがインフラエンジニアに求められる要素だと考えています。
前置き（エラー解決を急いでいる人は読み飛ばして下さい）
プロジェクトでは開発エンジニアからは実装したものを動かしてみたいという要望があがることが多々あります。
「了解、今からデプロイするから10分待って」
というやりとりが必要な場合、インフラエンジニアがデプロイするまでに10分間の待ちが発生してしまうことになります。実際には、連絡してから返答をするまでの間もありますので、10分以上の待ちが発生します。この時間、無駄じゃないですか？
そこで必要になるのが、デプロイ自動化ですが、弊社ではCodeDeployを使うケースが少なくありません。
せっかく実環境で試したことをアウトプットしないのはもったいないのでトラブルシュートから小ネタまで少しずつ書いて行こうと思います。
CodeDeployでEC2へデプロイした結果、処理が1つも進まずに失敗してしまうとき
このような状況の時、CodeDeployのコンソールに下記のエラーが出力されていると思います。
The overall deployment failed because too many individual instances failed deployment, too few healthy instances are available for deployment, or some instances in your deployment group are experiencing problems.
※実際の画面
CodeDeploy Agentのログを確認する
CodeDeploy Agentのログは /var/log/aws/codedeploy-agent/codedeploy-agent.log に出力されています。
$ tail -10 /var/log/aws/codedeploy-agent/codedeploy-agent.log 2020-07-16 03:06:01 INFO [codedeploy-agent(3374)]: Version file found in /opt/codedeploy-agent/.version with agent version OFFICIAL_1.1.0-4_rpm. 2020-07-16 03:06:01 ERROR [codedeploy-agent(3374)]: InstanceAgent::Plugins::CodeDeployPlugin::CommandPoller: Missing credentials - please check if this instance was started with an IAM instance profile 2020-07-16 03:07:31 INFO [codedeploy-agent(3374)]: Version file found in /opt/codedeploy-agent/.version with agent version OFFICIAL_1.1.0-4_rpm. 2020-07-16 03:07:31 ERROR [codedeploy-agent(3374)]: InstanceAgent::Plugins::CodeDeployPlugin::CommandPoller: Missing credentials - please check if this instance was started with an IAM instance profile 2020-07-16 03:09:01 INFO [codedeploy-agent(3374)]: Version file found in /opt/codedeploy-agent/.version with agent version OFFICIAL_1.1.0-4_rpm. 2020-07-16 03:09:01 ERROR [codedeploy-agent(3374)]: InstanceAgent::Plugins::CodeDeployPlugin::CommandPoller: Missing credentials - please check if this instance was started with an IAM instance profile 2020-07-16 03:10:31 INFO [codedeploy-agent(3374)]: Version file found in /opt/codedeploy-agent/.version with agent version OFFICIAL_1.1.0-4_rpm. 2020-07-16 03:10:31 ERROR [codedeploy-agent(3374)]: InstanceAgent::Plugins::CodeDeployPlugin::CommandPoller: Missing credentials - please check if this instance was started with an IAM instance profile 2020-07-16 03:12:01 INFO [codedeploy-agent(3374)]: Version file found in /opt/codedeploy-agent/.version with agent version OFFICIAL_1.1.0-4_rpm. 2020-07-16 03:12:01 ERROR [codedeploy-agent(3374)]: InstanceAgent::Plugins::CodeDeployPlugin::CommandPoller: Missing credentials - please check if this instance was started with an IAM instance profile
ログに出力されている InstanceAgent::Plugins::CodeDeployPlugin::CommandPoller: Missing credentials - please check if this instance was started with an IAM instance profile これがエラーの原因です。設定を見直してみましょう。
デプロイ対象のEC2にIAMロールをアタッチする
CodeDeployからEC2インスタンスへデプロイする場合は、CodeDeploy Agentのインストールだけではなく、IAMロールのアタッチが必要です。下記のドキュメントを参考にIAMロールをアタッチして下さい。
docs.aws.amazon.com
CodeDeploy Agentを再起動する
EC2インスタンスへIAMロールをアタッチしているけど、IAM instance profile のログが出力されている場合は、CodeDeploy Agentの再起動がされていないことが原因です。
CodeDeploy Agentは起動時にインスタンスプロファイルをチェックしていると思われます。そのため、IAMロールをアタッチしたあとは、CodeDeploy Agentを再起動する必要があります。
再起動は下記のコマンドを参考にして下さい。
・CodeDeploy Agent再起動
$ sudo systemctl restart codedeploy-agent.service
・CodeDeploy Agentのステータス確認(activeになっていることを確認)
$ systemctl status codedeploy-agent.service
これでIAM instance profile のログ出力が止まったことを確認した後、再度、CodeDeployからデプロイ実行してみましょう。
CodeDeployは便利なサービスなので積極的に使っていきたいですね！
JAWS SONIC 2020 / MIDNIGHT JAWS 2020 配信振り返り その３
JAWS SONIC / MIGNIGHT JAWS 2020配信振り返り記事です。このシリーズも今回でラストとなります。
- 今回はイベント当日をまとめていきます
- 当日の配信班担当分け
- シフトを組んで配信を行う
- イレギュラー対応には心構えをしておく
- Amazon IVS + AWS Elemental MediaLiveで27時間連続配信達成
- 動画アーカイブとYouTube公開
- 反省とまとめ
今回はイベント当日をまとめていきます
ざっくりとした内容はこちら。
- 当日の配信班担当分け
- シフトを組んで配信を行う
- イレギュラー対応には心構えをしておく
- Amazon IVS + AWS Elemental MediaLiveで27時間連続配信達成
- 動画アーカイブとYouTube公開
- 反省とまとめ
では、１つずつ書いていこうと思います。
当日の配信班担当分け
JAWS SONIC 2020 の配信班は、リモート３人+ オフライン３人+緊急時サポート1人 の構成でチームを組んでいます。
・リモート３人の担当内訳 ・OBSオペレーション担当：２名 ・登壇者誘導：１名 ・オフライン３人の担当内訳 ・OBSオペレーション担当：全員で交代 ・登壇者誘導：２名で交代 ・上記以外に配信状態のチェックは配信班全員で行います。
共通の配信環境が必要となるため、Amazon WorkSpaces上にOBSをセットアップし、配信環境を用意する形としました。全員各自の端末から配信用のWorkSpacesにログインしてオペレーションを行います。
私はオフライン３人のうちの1人でしたが、やはりオフラインはコミュニケーションが取りやすく、オペレーションをスムースに進めることができました。
成熟していない配信チームは、できるだけオフラインの方がトラブルなく進められる可能性が高いです。密を避けるということを考えると、２〜３名のオフラインチームを複数構成することがベストなのではないかと思います。
また、２４時間配信という環境下ではオフラインで顔を見ながら作業することが、テンションやモチベーションを保ち続ける大きな要因になったのではないかと考えています。なぜなら、配信中はリモートで常時音声で会話することが難しいためです。オフラインではセッション配信中はマイクをミュートにしていますので、会話しながら対応することが可能です。
シフトを組んで配信を行う
JAWS SONIC 2020は、24時間連続配信(当日の準備を含めると27時間連続配信)を行います。シフトを構成し、休憩時間の確保を行うことが必要です。１シフト２〜３名でおおよそ6時間交代でシフトを構成しました。
8時間などの配信の場合も、シフトは組んで体制のバックアップが効くようにチーム編成をした方が良いですね。
なお、当日は配信を行うにつれテンションが上り元気な状態が継続して、オフラインチームはシフト通りではなく、ほとんど画面の前で何かしらの作業をしていました。
イレギュラー対応には心構えをしておく
何事もトラブルや予定変更をゼロにすることは不可能です。結果的にゼロであったとしても、それは結果論でしかなく、トラブルに備えておくことが必要です。
トラブルとして下記のようなことが考えられます。
- スピーカーが来ない、連絡がとれない
- 配信用のコンテンツが揃わない
- 尺が延びてしまう(セッションオーバータイム)
- サービス障害などで配信が停止する
いずれのケースもJAWS SONIC 2020 では、発生した時にどうするかという打ち合わせ、対策を用意していました。
皆さんも経験があるかも知れませんが、トラブルへの備えがあるときはトラブル自体が起こらず、大丈夫だろうと備えていなかった時に限ってトラブルが起こるという経験があったため、お守り代わりに対策を用意していたという個人的な背景もあります。
Amazon IVS + AWS Elemental MediaLiveで27時間連続配信達成
JAWS SONIC 2020 の配信結果はこちらです。
・スピーカー当日欠席： ゼロ ・タイムテーブルとのギャップ： オンタイム ・オペレーショントラブル： ゼロ ・配信トラブル： ゼロ ・体調不良者： ゼロ
全てオンタイムで映像トラブル・音声トラブルもなく、配信を行うことができました。問題なく配信を行えたのは、配信班だけの力ではなく、JAWS SONIC 2020 & MIDNIGHT JAWS 2020に関わった皆様のおかげです。
あらためて、スピーカーの皆様、Web班、マーケ班、動画作成班そして、視聴下さった皆様ありがとうございました。
Amazon IVSのコンソールでは26時間以上連続配信できている様子が確認できます。このあと、イベント本編終了後の懇親会案内を止めるまで26時間45分問題なく配信されていました。
動画アーカイブとYouTube公開
JAWS SONIC 2020 & MIDNIGHT JAWS 2020の様子は一部を除くYouTubeチャンネルでアーカイブ公開しています。
アーカイブは Elemental MediaLive のアーカイブ機能を利用し、600秒間隔でtsファイルとしてS3に出力する形を採用しました。
アーカイブ公開は600秒ごとに分かれた24時間分のtsファイルを変換して編集し、セッションごとにYouTubeに登録するという気の遠い作業です。
この作業は、配信班の１人でもある、北海道テレビ放送の三浦さんが対応してくれました。めちゃくちゃ大変だったと思います。ありがとうございました。
反省とまとめ
最後に配信班の取り組みとして、良かったこと、こうすればよかったこと、をまとめておきます。
・登壇者の誘導は分岐を設けず、ストレートにする ・手順書、オペレーションガイドは必須 ・登壇者向けリハ、オペレーションリハも必須 ・視聴者向けのテスト環境を用意するべきだった ・切り替え時間は３分が限界(視聴側を考えると３分がベスト) ・ロケーションが一緒だとめちゃくちゃ楽 ・２４時間配信は８〜1０名くらいの体制が必要(今回は6名)
コミュニティ放送部で登壇した際の資料にもありますので是非こちらもご覧ください。
JAWS SONIC 2020 & MIDNIGHT JAWS 2020 は24時間という長さこそ大変でしたが、参加したことで得られたものはそれ以上でした。やっぱり祭りは外で見るより、中にいた方が最高に楽しいです。
配信自体はサービスを使うことで求められる専門知識も少なくなっています。ZoomやStreamYardなどのサービスを使うことで誰でも気軽に配信ができます。
ただ、オンラインイベントの場合、単なる配信だけではなく事前準備やイベントを上手く進めるための工夫が必要となります。振り返り記事は配信班として事前準備やイベントを上手く進めるために必要だったことにフォーカスして書いています。
この振り返り記事がオンラインイベント配信に関わる皆さんの役に立てれば嬉しいです。
