Tag: AWS

cheatsheet/aws/medialive

Posted: 2021-10-13 | Categories: cheatsheet | Tags: AWS, cheatsheet, MediaLive

チャンネル操作

効果	コマンド
チャンネルのリスト	aws medialive list-channels –region ap-southeast-1 \| jq -r ‘.Channels[].Id’)
止める	aws medialive stop-channel –channel-id チャンネル ID
削除	aws medialive delete-channel –channel-id チャンネル ID
作成	aws medialive create-channel –cli-input-json file://channel_sample.json \| jq ‘.Channel.Id’
開始	aws medialive start-channel –channel-id チャンネル ID
インプットを作成する	aws medialive create-input –cli-input-json “$CREATEINPUT” –region ap-southeast-1
インプット id を調べる	aws medialive list-inputs –region ap-southeast-1 \| jq -r ‘.Inputs[].Id’
インプット id から詳細を得る	aws medialive describe-input –input-id インプット ID –region ap-southeast-1
インプット用のスケルトンを得る( 上記の json より、Destinations の雛形が良い )	aws medialive create-input –generate-cli-skeleton

セキュリティグループの雛形を得る

aws medialive create-input-security-group --generate-cli-skeleton
{
    "WhitelistRules": [
        {
            "Cidr": ""
        }
    ]
}

こんな感じにしたい

WordPress、kusanagiでのアップデート

Posted: 2021-09-10 | Categories: KUSANAGI | Tags: AWS, KUSANAGI, WordPress

アップデート手順

システム構成

AWS 上で CloudFront + ALB + EC2 + RDS の構成で運用中。
SSL アクセラレーターは ALB
RDS は毎日スナップショットを取れる運用。
アップデート前には_AMI から検証用 Wordpress を別に構築する。

WordPress はアップデートに失敗すると、真っ白になったりする、と聞いたので別サーバーを立てて検証してからアップデートを試みた方が良いと思う。

デフォルトの状態だとアップデートできなかった。

素直にアップデートはできなかった

別サーバーを立てて検証中、怖い表示になった。本番とは別にサーバーを立てて検証してて助かった。

このサイトで重大なエラーが発生しました

事前のステージング環境での確認

作業前に対象ドメインの Wordpress で非公開のページを作っておく( これを目印にする )
RDS, EC2 をそれぞれバックアップから作成する
EC2 が参照する RDS を新しく作ったものに変更する
EC2 をロードバランサー配下に追加する

本番での作業の流れ

後述するが下記のような流れ

作業前に対象ドメインの Wordpress で非公開のページを作っておく( これを目印にする )
RDS, EC2 をそれぞれバックアップから作成する
EC2 が参照する RDS を新しく作ったものに変更する
EC2 を新しく作ったロードバランサー配下に追加する
ローカル PC の/etc/hosts を修正し、対象ドメインを新しいロードバランサーの IP アドレスに変更する
再度、アクセスし[0]で作った目印が「無い事」を確認する
アップデートの検証を行う
アップデートが正常にできたら EC2 をターゲットグループ内の EC2 インスタンスを新旧を入れ替える
[4]で /etc/hosts で追加した箇所をコメントアウト
対象ドメインの動作を確認する

RDS のスナップショットから DB 作成

RDS、スナップショットリスト=>[システム]=>[前日のスナップショットのチェックボックスをオン]=>[アクション]=>[スナップショットを復元]

nuxt向けのCloudFront設定

Posted: 2021-08-21 | Tags: AWS, CloudFront, nuxt

nuxt用の設定についてまとめた

nuxt.js向けのCloudFront設定をまとめた。

オリジンとCDNの関係

CloudFrontでは、複数のオリジンサーバを指定可能。例えば s3 や複数のALBで振り分ける事ができる( Layer7レベルでの振り分けが可能 )、更にALBはリスナーに設定を追加することで複数のドメインをLayer7レベルで振り分けられる。

ALBで、FQDNで正しいターゲットグループに振り分けられる用に設定する
CloudFrontで、 ALBの名前を指定する www-36?????.ap-northeast-1.elb.amazonaws.com ( CloudFront から ALB に要求されるFQDNの情報は飛ぶ )
Route53 で、ユーザーがアクセスするFQDNをCloudFrontに振り向ける

それぞれの手順を下記に残しておく

1. ALBで、FQDNで正しいターゲットグループに振り分けられる用に設定する

ロードバランサー -> リスナー -> ルールの表示` をクリックして、Layer7設定を確認。

目的のFQDNが存在するか?
ALBからの転送先が存在するか?
転送先のターゲットグループにはサーバは存在するか? を確認する。

CloudFront設定

設定する前に…

SSL証明書はAWSで発行済か( CloudFrontのSSL証明書はバージニア北部に存在する必要がある )
ALBの設定はできているか
s3にログ用のバケットはあるか

を確認したほうが良い( でないと、CloudFrontの設定をやり直す必要がある )

オリジンサーバとしてALBのFQDN( dandelive-eikoh-51???.ap-northeast-1.elb.amazonaws.com のようなもの、EC2の「ロードバランサー」のページで確認できる)

オリジンサーバでALBを登録後、振る舞いとして /nuxt/配下を追加する。デフォルトはキャッシュしないが、/nuxt/配下はキャッシュする。

Minimum Origin SSL Protocol : TLSv1
Origin Protocol Policy : HTTPS Only ( 暗号化された通信だけにしたい )
Origin Response Timeout : 60
Viewer Protocol Policy : Redirect HTTP to HTTPS ( http接続はhttpsにリダイレクトして暗号化を促す )
Allowed HTTP Methods : GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE
Origin Keep-alive Timeout : 60 ( コネクションを再接続するコストを払わない )
Cache and origin request settings : 「Use a cache policy and origin request policy」と「Use legacy cache settings」がある。以前は legacy に該当する設定しかなかった。最初に設定するオリジンはキャッシュしないポリシー「CachingDisable」を選択する。
Origin Request Policy : Managed-AllViewer ( 全てのリクエストヘッダ、クッキーなどをオリジンに通す )
Alternate Domain Names (CNAMEs) : test.net ( 都度、変えること )

Behaviors を追加する

CloudFrontを設定( ディストリビューションの設定 )を追加するウィザードで設定されるのは、デフォルトのアクセスだけなので、 /_nuxt のようなURLごとの設定の場合、設定を追加する必要がある。

passenger

Posted: 2021-08-19 | Categories: AWS | Tags: AWS, CanvasLMS, Passenger

Canvas LMS の起動に時間がかかりすぎて Passenger が落ちる

Canvas LMS というラーニングマネージメントシステムの運用中、Passenger が再起動を繰り返す症状になった。何度か再起動を繰り返すと、たまに立ち上がる。

Canvas LMS は重量級のアプリケーションなので起動に時間がかかっている事が原因と仮定して急場を凌ぐためサーバーの性能を上げると症状は解消した。

ただできれば安く運用したいため原因を調べ Passenger 側のタイムアウト値を伸ばすことで解消した。

環境

Ubuntu 18.04 Canvas LMS バージョン 2021/04/14 21:24:27 リリースのもの

原因

Apache の下記のようなログが出ていた。

[ E 2021-08-19 12:51:59.9818 2620/Tf age/Cor/App/Implementation.cpp:221 ]: Could not spawn process for application /var/canvas: A timeout occurred while starting a preloader process.
  Error ID: 5601fca6
  Error details saved to: /tmp/passenger-error-rBz6ES.html

Passenger は問題が起きた時 /tmp 配下にログを吐き出す。 /var/log/syslog ではなく絶えず吐き出すわけではないので問題を難しくしているようにも思うが。

# find / -name 'passenger-error*html'
/tmp/systemd-private-0af79b8b175f43b4a340f69608070e76-apache2.service-Ga9LrA/tmp/passenger-error-rmclOc.html
/tmp/systemd-private-0af79b8b175f43b4a340f69608070e76-apache2.service-Ga9LrA/tmp/passenger-error-rBz6ES.html

html をブラウザで見ると、[ What happened? ]、[How do I solve this ]、[Get help]、[Detailed diagnostics]があり、 [How do I solve this ]を見ると、

簡単な EC2 インスタンスのバックアップ機構を作る

Posted: 2020-10-06 | Categories: AWS | Tags: AWS, EC2

日次で自動的に cron で再起動して、AMI イメージを取得したい。再起動が必要だが再起動時はメンテナンス画面を出しておきたい( 深夜メンテナンス時間が取れるサービスに限る ) ALB でメンテナンス画面を出せる機能を用いてサーバ終了、起動時にメンテナンス画面に切り替える

仕組み

EC2 上で自分自身のイメージを取得するスクリプトを用意する
EC2 の IAM ロールで AMI 化を実行するのに必要な権限を付与する
EC2 サーバの crontab にスクリプトを用意する
起動終了時に ALB のルールのプライオリティを変更する処理を組み込む

EC2 上で自分自身のイメージを取得するスクリプトを用意する

/usr/local/bin/ami_backup.bash に下記のスクリプトを設置した。

#!/bin/bash

id=$(/usr/bin/curl -s http://169.254.169.254/latest/meta-data/instance-id)
/usr/bin/aws ec2 create-image --region ap-northeast-1 --instance-id $id --name "wordpress-www-update-$id-$(date +%Y%m%d%H%M)" --reboot

wordpress-www-update の部分はシステムによって変えた方が良いと思う。あるいは$id にインスタンス名が入るので、それを持ってユニークとするか( ただし検索が面倒 )

EC2 の IAM ロールで AMI 化を実行するのに必要な権限を付与する

下記のロールを持つように IAM を作成、EC2 サーバーに付与

elasticloadbalancing はロードバランサーのルールのプライオリティの上下に使う
ec2 は AMI の作成に使う

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "elasticloadbalancing:DescribeRules",
                "elasticloadbalancing:SetRulePriorities",
                "ec2:ExportImage",
                "ec2:DescribeImages",
                "ec2:DeleteTags",
                "ec2:EnableImageDeprecation",
                "ec2:CreateTags",
                "ec2:RegisterImage",
                "ec2:CreateImage",
                "ec2:ModifyImageAttribute",
                "ec2:CreateStoreImageTask",
                "ec2:DisableImageDeprecation"
            ],
            "Resource": "*"
        }
    ]
}

EC2 サーバの crontab にスクリプトを用意する

AM 03:01 に実施

ALBのメモ

Posted: 2020-03-10 | Categories: aws | Tags: alb, aws

背景

AWSが悪いわけではない、大抵、自分が悪い。自分の何が悪いのか分析したい

ALBのログを解析する

ログのステータスコードの意味

Application Load Balancer のトラブルシューティング

502 エラーの場合

ALBの「アイドルタイムアウト」とステータスコード502,504の話 - PLAY DEVELOPERS BLOG
- 凄くまとまっていた。アプリケーションの実行時間という考え方も必要。でも502エラーも出したくない

状況としては

ALBはターゲットのコンピューティングノードに接続しようとしている
ALBはターゲットのコンピューティングノードに接続しようとしてるが、コンピューティングノード側が切れている

なぜ切れているのか? 様々な理由がありえるだとう

コンピューティングノード側が短い
- 基本的にALB側を短くすべき( ALB主体で切るようにすればコンピューティングノード側で先に切ることはない )
コンピューティングノード側が切れている
- Nginx、Ruby、php-fpmなどのポートは、その時に受け入れられる状態だったのか?
Application Load Balancer の属性を編集する - エラスティックロードバランシング
- 接続のアイドルタイムアウト
  - 接続アイドルタイムアウトとは、ロードバランサーが接続を終了する前の、既存のクライアントまたはターゲット接続が非アクティブのままでデータの送受信が行われない時間のことです。

ALBのメモ

Posted: 2020-03-10 | Categories: aws | Tags: alb, aws

ALBのログ
- Application Load Balancer のアクセスログ - Elastic Load Balancing
Datadogのメトリクス
- Amazon Elastic Load Balancing

AWS Organizationsで作った環境でVPCを作っていく

Posted: 2019-08-03 | Categories: AWS | Tags: AWS, Organization, VPC

作業の流れ

AWS OrganizationでOrganization Unit ( OU )作成、AWS Organization 内で AWSアカウントも作成
VPC作成、サブネットを各AZごとに合計3つ作成
VPC内でインターネットゲートウェイ作成, 作成したVPCに紐付け

AWS、アカウント作成直後のネットワーク設定

実作業

AWSの具体的なリソースは省略しています。得られた値で読み替えてください。

VPC作成

プロファイルは都度、変更してください
–cidr-block は既存サブネットと被らないように取得してください
vpcのタグ名は都度、変更する

CLIでの作成はここが非常に参考になります

aws ec2 --profile test-site create-vpc --cidr-block "172.37.0.0/16" --tag-specifications  "ResourceType=vpc,Tags=[{Key=Name,Value=prod}]"

{
    "Vpc": {
        "CidrBlock": "172.37.0.0/16",
        "DhcpOptionsId": "dopt-08f0bf2e614f696d8",
        "State": "pending",
        "VpcId": "vpc-04d******"
        "OwnerId": "*************",
        "InstanceTenancy": "default",
        "Ipv6CidrBlockAssociationSet": [],
        "CidrBlockAssociationSet": [
            {
                "AssociationId": "vpc-cidr-assoc-",
                "CidrBlock": "172.37.0.0/16",
                "CidrBlockState": {
                    "State": "associated"
                }
            }
        ],
        "IsDefault": false,
        "Tags": [
            {
                "Key": "Name",
                "Value": "prod"
            }
        ]
    }
}

また上記のCLIで作成した際の「 “VpcId”: “vpc-???“このVpcId の値は使うのでメモしておく

AWS Organizations関連のメモ

Posted: 2019-08-03 | Categories: AWS | Tags: AWS, Organization

AWS Organizations でアカウント管理してみる - ユニファ開発者ブログ

久しぶりに作業した時には、ざっと目を通す AWS Organizations の用語と概念 - AWS Organizations

手順

ログイン https://console.aws.amazon.com/organizations/home?region=ap-northeast-1#/accounts
[ アカウントの追加 ]->[ アカウントの作成 ]
フルネーム: example-admin
Eメール: admin@example.com
IAM ロール名: OrganizationAccountAccessRole [ 作成 ]をクリック

組織を作成する

[ Create organizational unit ]( [ 新規組織単位 ] )をクリック。組織名を入力。ハイフンを利用可能だった。使わなくても良いが。

アカウント( というかOrganization のアカウント )の作成

[ Account ]->[ Add account ]->[ Create account ]

一旦、アカウントを作成、実際に使うOrganizationに紐付ける、という作業を行う

アカウント( というかOrganization のアカウント )の情報入力

[ アカウントの追加 ]->[ アカウントの作成 ]
フルネーム: hoge.co-dev
Eメール: system+dev@hoge.com
IAM ロール名: OrganizationAccountAccessRole [ 作成 ]をクリック

Organizationをアクティベートする

作成したOUの画面で、歯車アイコンをクリックする

CloudWatch logsのログをinsightで検索

Posted: 2018-08-21 | Categories: AWS | Tags: AWS, CloudWatch

ログについては、ひとまずCloudWatch logsに投げ込む運用にしています(注1

このCloudWatch logsを高速に検索できるインサイトをCLIから使う紹介です( WEBでの使い方については[ CloudWatch ]->[ インサイト ]でいろいろ試していただきたいです ) 障害調査の場合、どのみちgrepすることになるのでCLIでの手順も残しておきます。

ログ取得

https://docs.aws.amazon.com/ja_jp/AmazonCloudWatchLogs/latest/APIReference/API_StartQuery.html

--start-time 開始時刻をunixtime
--end-time 終了時刻をunixtime
--query-string 参考 https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/logs/CWL_QuerySyntax.html

クエリ(フィルタリング)について

検索する際の方法 limit 10 とか。

このためにインサイトを使っていると言えますが正規表現

| filter @message like /access_token=/

クエリ例

参考: サンプルクエリ - Amazon CloudWatch Logs

nginxのログのみを表示する

| filter @logStream LIKE /nginx/

ロードバランサからのヘルスチェックを除外する

| filter @message NOT LIKE /ua:ELB-HealthChecker/

ステータスコードが500番台のもののみを表示する

| filter @message LIKE /status:5\d+/

ログをパースして変数にセットする

| parse @message "time:*host:*forwardedfor:*req:*status:*size:*referer:*ua:*reqtime:*cache:*runtime:*vhost:*userid:*" as time, host, forwardedfor, req, status, size, referer, ua, reqtime, cache, runtime, vhost, userid

クエリ実行( ログ検索は時間がかかるため、後で別途getする必要があります)

bash環境(dateコマンドはbrewのcoreutilsを使用)

MediaLiveをCloudWatchで監視する

Posted: 2018-08-21 | Categories: AWS | Tags: AWS, CloudWatch, lambda, MediaLive

背景

MediaLive ですが、いろいろなエラーを通知してくれます。

やれ「RTMP 接続が切れたよ」とか「オーディオ入力 or ビデオ入力が無いよ」とかですね。通常、ライブ配信が始まる前は当然、MediaLive への入力は無いはずなので、通知は構わないのですが、ライブ配信中に出ると、それはもうトラブルシューティングの情報の一つとして重要なものになります。 ( というか当初、エラーは出てるっぽいし、挙動はおかしいんだけど、どんなエラーが出てるか分からないケースがあって窮地な時がありました )

今は管理画面の[ channels ]->[ 目的のチャンネル ]->[ Alerts ]から確認できます。が、ログとして残しておくのは良い事だと思います。このエラー出力のフォーマットは決まっている訳ではなく、たまに変わります。ので『あー、エラー出力が変わったからアラートが上がらなくなったのね』、という事がログを残しておくと分かります。

手順

WebUI

SNS のページ( https://ap-northeast-1.console.aws.amazon.com/sns/ )を開く
[ トピック ]->[ 新しいトピックの作成 ]->トピック名の入力、私は[ MediaLiveEvent ]、表示名[ MediaLiveEvent ]と入れてみた
作成したトピックの ARN をコピペ arn:aws:sns:ap-northeast-1:123456789012:MediaLiveEvent
同じ SNS 内の左側メニュー->[ サブスクリプションの作成 ]
[ トピック ARN ]に先程作成した MediaLive のトピックの ARN を入力
プロトコルメール(ほかにも lambda とかから Slack に送信できたりする)
エンドポイント : 自分のメールアドレス

はじめてのアラートメール設定の場合、AWS から確認のメールが飛ぶ

[ AWS Notification - Subscription Confirmation ]という件名のメールがあったらメール本文内のリンクをクリック

CloudWatch

cloudwatch のページに移動*
[ イベント ]->[ ルールの作成 ]
[ イベントパターン ]になってること
[ カスタムイベントパターン ]に変更カスタムイベントパターンの内容としては下記を入力

{
  "source": [
    "aws.medialive"
  ]
}

右側の[ ターゲットの追加 ]->[ SNS トピック ]に変更->[ トピック ]はプルダウンメニューから先程、作成した SNS のトピックを選択
[ 設定の詳細 ]
ルールの定義
名前: 任意
説明: 任意
[ ルールの作成 ]
メールボックスを確認

CLI

参考: SNS をコマンドラインから設定する : 電子の密林を開拓する

ローカルサーバからCloudWatchに送信してアラートを設定する

Posted: 2018-08-21 | Categories: AWS | Tags: AWS, CloudWatch

CloudWatchのアラートを設定する方法

ここでは各環境向けにCPUとメモリ使用率のアラートを設定する方法を共有します。以下で説明する alarms.sh、 alarm_mem_template.json、 alarm_cpu_template.json の3つのファイルを用いて作業します。

alarms.sh

各ECSサービスのアラームの設定をするShell Scriptです。 alarms.shの名前で以下の内容のファイルを作成します。このスクリプトでは現在作成されている環境を全て取得し、そのそれぞれに対して、すでに同名のアラームがある場合には更新、存在しない場合には新規にアラームを作成します。そのため新しい環境を追加し、CPUおよびメモリ使用率のアラートを設定したい度に実行する必要があります。

#!/bin/bash
services=$(aws ecs list-services --cluster=test-dev-20181030-1 | jq -r .serviceArns[] | sed  s#.*/##g)
THRESHOLD_MEM=70
THRESHOLD_CPU=70

for service in ${services[@]}; do
  SERVICE=$service THRESHOLD_MEM=$THRESHOLD_MEM envsubst < ./alarm_mem_template.json > alarm_mem.json
  SERVICE=$service THRESHOLD_CPU=$THRESHOLD_CPU envsubst < ./alarm_cpu_template.json > alarm_cpu.json
  aws cloudwatch put-metric-alarm --cli-input-json file://alarm_mem.json
  aws cloudwatch put-metric-alarm --cli-input-json file://alarm_cpu.json
done

使い方

alarms.sh を作成したディレクトリに alarm_mem_template.json と alarm_cpu_template.json をそれぞれ以下の内容で作成します。

alarm_mem_template.json

{
  "EvaluationPeriods": 3,
  "TreatMissingData": "missing",
  "ComparisonOperator": "GreaterThanThreshold",
  "ActionsEnabled": true,
  "AlarmActions": [
    "arn:aws:sns:ap-northeast-1:123456789012:alert2Slack"
  ],
  "OKActions": [
    "arn:aws:sns:ap-northeast-1:123456789012:alert2Slack"
  ],
  "Namespace": "AWS/ECS",
  "Period": 60,
  "Threshold": ${THRESHOLD_MEM},
  "AlarmName": "Memory Utilization of ${SERVICE} alert to Slack",
  "Dimensions": [
    {
      "Name": "ClusterName",
      "Value": "test-dev-20181030-1"
    },
    {
      "Name": "ServiceName",
      "Value": "${SERVICE}"
    }
  ],
  "DatapointsToAlarm": 3,
  "Statistic": "Average",
  "MetricName": "MemoryUtilization"
}

alarm_cpu_template.json

{
  "EvaluationPeriods": 3,
  "TreatMissingData": "missing",
  "ComparisonOperator": "GreaterThanThreshold",
  "ActionsEnabled": true,
  "AlarmActions": [
    "arn:aws:sns:ap-northeast-1:123456789012:alert2Slack"
  ],
  "OKActions": [
    "arn:aws:sns:ap-northeast-1:123456789012:alert2Slack"
  ],
  "Namespace": "AWS/ECS",
  "Period": 60,
  "Threshold": ${THRESHOLD_CPU},
  "AlarmName": "CPU Utilization of ${SERVICE} alert to Slack",
  "Dimensions": [
    {
      "Name": "ClusterName",
      "Value": "test-dev-20181030-1"
    },
    {
      "Name": "ServiceName",
      "Value": "${SERVICE}"
    }
  ],
  "DatapointsToAlarm": 3,
  "Statistic": "Average",
  "MetricName": "CPUUtilization"
}

上記2つのファイルがある状態で $ ./alarms.sh を実行すると、各環境のCPU、メモリの使用率のアラートが設定することができます。

redisのスケールダウン手順

Posted: 2018-08-03 | Categories: AWS | Tags: AWS, ElastiCache

redisのスケールダウン手順

手順

大きな作業の流れ。このページから複数ページに飛ぶようになっているので、作業ボリュームを見誤らないように。 https://docs.aws.amazon.com/ja_jp/AmazonElastiCache/latest/UserGuide/Scaling.RedisStandalone.ScaleDown.html

バックアップを取得する( m3インスタンス以上でないとバックアップは取れない模様。t2で検証したが取れなかった )

バックアップ自体は無停止( 内部的にはredisのBGSAVEが動いているようだ )

Webコンソールでのステータスは[ snapshotting ]に変わる。

バックアップから復元する

バックアップ完了後、バックアップイメージから新しく立ち上げ直す。既存のクラスターは削除する。エンドポイントを付け替える、などを期待して検証したが、そういう機能は無かった。

https://docs.aws.amazon.com/ja_jp/AmazonElastiCache/latest/UserGuide/backups-restoring.html#backups-restoring-CON

[ 管理コンソール ]->[ バックアップ ]->該当バックアップを選択->リストア
[ クラスターID ]は作成したいエンドポイントを考慮して正確に作成する

動作確認

キーが帰ってくるか

redis-cli -p 6379 -h test.hoge.ng.0001.apne1.cache.amazonaws.com  --scan --pattern '*'  | less
redis-cli -p 6379 -h test.hoge.ng.0001.apne1.cache.amazonaws.com GET _PHCRhoge.v2.user-status-11111

AWS MediaLive + MediaPackageを使ってライブ配信

Posted: 2017-12-04 | Categories: AWS | Tags: AWS, MediaLive, MediaPackage

目的

2017/11 にリリースされた AWS メディアサービスを使って、ラクして動画配信したい。できる限り遅延は無い方向で！まずざっくりとした使い方を把握して、どの程度、細かく設定できるのか知りたい！ ( 実際のスマホでの確認までではなく、PC 上でエンコードされたライブが見えるところまでが今回のゴール )

作りたいシステム構成

ライブカメラ -> Wirecast -> RTMP(ないし RTSP) -> エンコーダー -> CDN -> ユーザ

CDN 使うと大規模に安く配信できるので使いたい。が、当然できる限り遅延は少なくしたい。

感想

あとマルチビットレートの設定が最初から入っているのとか、冗長化を初めから考慮されてる設定は素敵。 2017/12/04 時点では、MediaPackage で選択可能な配信フォーマットは HLS のみでした。Mpeg-DASH とか必要な場合は、対応待ちです。

ただ、UI というか画面遷移が迷うところが多いし、一通り設定が完了しないと、カメラからのデータを送れないしで、挫けそうになりました。この辺は時間が解決してくれるよ！という気持ちで。

背景

EC2 で wowza や AdobeMediaServer 立てて運用するのはもちろんありだし、カスタマイズ性はこちらの方が高そうではある(インスタンスプランも選択できるし) が、運用コストはかかるのでありできれば減らしたい。

AWS メディアサービスって?(複数サービスの集合でした)

参考クラウドベースの映像処理、保存、収益化 classmethod 様

2017/12 現在、MediaConvert、MediaLive、MediaPackage、MediaStore、MediaTailor という 5 つのサービスで構成されています。このうち、自分に必要そうな『MediaLive』『MediaPackage』のみを使ってみました。 VOD、および他動画解析サービスなどと連携する場合は S3 に保存する MediaStore も併せて使う必要があるかもしれません。

設定方法

MediaLive について

(先に MediaPackage から設定する必要があります ) 当初、名前に Live ってあるし、MediaLive だけで完結できるか?と思いきやできず… なんか、CDN から見えるはずのオリジンサーバに該当する設定が無くね? どこで作るの? と見つからなかった。 MediaLive は「カメラから入ってきたデータをエンコードして Push する」という機能までなので、それを「CDN などから Pull するための機能は『MediaPackage』が担当する」という事に気づかなかった。ので先に MediaPackage の設定から行う必要があります。

aws/codebuild

Posted: 2017-08-08 | Categories: AWS | Tags: AWS, CodeBuild

CodeBuildで設定した方が良さそう環境変数リスト

※ サービス固有に設定した方が良さそうな環境変数もあるので注意が必要( たとえば外部サービスの鍵など )

変数	用途	例
${AWS_ID}	開発と本番で共通のbuildspec.ymlを利用したい。それぞれAWS IDが異なるので環境変数で設定可能にする。
${API_ROOT}	開発時に参照するエンドポイントと本番系は異なるため	開発: dev.hoge.com 本番: wwww.hoge.com
${NODE_ENV}	開発時はdev、本番時はproductionを指定することが多い( productionを設定していると、yarn install時、devDependinciesが無視される) devはMac上の開発環境で使い、ECSはproductionを用いる	開発: dev 本番: production
${ECS_TASK}	開発時はenv**という名前でECSのリソース(タスク定義、サービス)をアサインする。本番系はenvではなくサービス名称を用いるため異なる。	開発: dev32 本番: wwwなど
${ECS_SERVICE}	開発、本番で異なるため
${ECS_CLUSTER}	ECSクラスター名も開発と本番で異なる(開発環境は都度クラスターを構築するのは工数がかかりすぎるので統一している。が本番系は別にクラスターを構築し、コンテナ間でリソースの上限やお互いのサービスの負荷の影響を与える可能性を考慮して、クラスターレベルで分離している)
${API_SHARED_ACCCESS_TOKEN}
${AWS_ACCOUNT_ID}
${AWS_DEFAULT_REGION}
${HOST_NAME}
${IMAGE_REPO_NAME}
${IMAGE_TAG}
${PORT}
${WWW_ROOT}

ECRのタグ( buildspec内でdocker pushしている )ポリシー

開発用のECSタスク定義で使用するDockerイメージには `dev` のタグをつける

イメージに対しては必ずタグをつける( タグがないイメージにアクセスしにくいので、実質的にバックアップの意味にもならない。

aws/codebuildで設定を複製する

Posted: 2017-08-08 | Categories: AWS | Tags: AWS, CodeBuild

CodeBuildの設定を複製する

環境固有の環境変数の修正がある。

既存の設定情報を取得する

aws codebuild batch-get-projects --names hoge-web | jq '.projects[0]' > ~/original.json

取得したjsonファイルを修正する

比較として、CodeBuildを作成する際に参考になるjsonは aws codebuild create-project –generate-cli-skeleton で取得可能

取得したjsonと –generate-cli-skeleton で取得した雛形を比較しながら、取得したjsonを修正する。

name を修正
arn は新規に割り振られるので削除
environment.environmentVariables を修正 IMAGE_REPO_NAME SERVICE_NAME
logsConfig.cloudWatchLogs.groupName を修正
badge を削除

反映

aws codebuild create-project –cli-input-json file://修正したもの.json

aws/rds

Posted: 2017-08-08 | Categories: AWS | Tags: AWS, RDS

replicaが高負荷になった

replica1のmax_connectionsを確認したところ上限値1000でした

mysql> show global variables like 'max_connections';
+-----------------+-------+
| Variable_name   | Value |
+-----------------+-------+
| max_connections | 1000  |
+-----------------+-------+
1 row in set (0.01 sec)

この障害はreplicaがボトルネックと断定できます。

AWS_RDS_Aurora_監査ログ取得のための変更

大体、ClassmethodのページのようにIAMを作成し付与します。

Classmethodのサンプルだと、全てのクエリをロギングする設定なので絞ります。クラスターパラメータグループを変えます。

[ RDS ]->[ クラスター ]->[ aurora ]->[ DB クラスターのパラメータグループ ]のリンクをクリック->[ フィルタパラメータ ]のテキストフィールドに[ audit ]を入力下記の要素がリストアップするので変更します。都度、[ 変更の保存 ]をする必要があります。

server_audit_events -> QUERY_DCL, QUERY_DDL, TABLE ここで、ロギング対象を絞ります。パラメータの詳細についてはここを参照
server_audit_excl_users -> 空欄 ( [If not empty, it contains the list of users whose activity will NOT be logged] 全てのユーザの変更を取りたいため空欄 )
server_audit_incl_users -> 空欄 ( [If not empty, it contains a comma-delimited list of users whose activity will be logged] )
server_audit_logging -> 1 ( ロギングを有効にする場合は 1 )
server_audit_logs_upload -> 1 (CloudWatch logsへログのアップロードを行う場合は 1 )

DBスナップショットの作成時のダウンタイム

Single-AZ DB インスタンスでこの DB スナップショットを作成すると、I/O が短時間中断します。この時間は、DB インスタンスのサイズやクラスによって異なり、数秒から数分になります。

結構ばらつきがあるのに注意が必要だ。

cheatsheet/aws/rds

Posted: 2017-08-08 | Categories: cheatsheet | Tags: AWS, cheatsheet, RDS

パラメーターグループ

作る

aws rds create-db-cluster-parameter-group \
  --db-cluster-parameter-group-name hoge-canvas-postgresql10 \
  --db-parameter-group-family aurora-postgresql10 \
  --description "for wal_level must be set to logical"

参考 aws rds create-db-cluster-parameter-group help

編集

aws rds modify-db-cluster-parameter-group \
  --db-cluster-parameter-group-name hoge-canvas-postgresql10 \
  --parameters "ParameterName=rds.logical_replication,ParameterValue=1,ApplyMethod=pending-reboot"

設定するパラメーターによっては即時反映 ApplyMethod=immediate が使えず

An error occurred (InvalidParameterCombination) when calling the ModifyDBClusterParameterGroup operation: cannot use immediate apply method for static parameter

というエラーが出る。この場合、 ApplyMethod=pending-reboot を使う必要がある。 staticかどうか?はWebUIの『タイプの適用』の箇所を見るとわかる。

反映

aws rds modify-db-cluster \
  --apply-immediately \
  --db-cluster-identifier hoge \
  --db-cluster-parameter-group-name hoge-canvas-postgresql10

パラメータグループ作成

パラメータグループ名: test-aurora
説明: utf8mb4
ファミリー: aurora5.6 を指定して、とりあえず設定自体を作る

$ aws rds create-db-parameter-group \
  --db-parameter-group-name test-aurora \
  --description utf8mb4 \
  --db-parameter-group-family aurora5.6 \

構築

aws rds create-db-cluster \
  --engine aurora-postgresql \
  --engine-mode serverless \
  --engine-version 10.12 \
  --copy-tags-to-snapshot \
  --enable-http-endpoint \
  --db-subnet-group-name prod \
  --vpc-security-group-ids sg-1111111111111111 \
  --db-cluster-identifier sample-cluster \
  --master-username postgres \
  --master-user-password himituno

既存のパラメータグループから情報をコピーする

aws rds describe-db-parameters –db-parameter-group-name test-aurora > rds-test-aurora.json

AWS KMSで鍵を保存、取得する

Posted: 2016-12-13 | Categories: AWS | Tags: AWS, aws-cli, KMS

AWS KMS を awscli から利用してみる

http://qiita.com/kanagi/items/2008aa9f43be26bd2746

classmethod AWS Key Management Serviceでキーの”管理”と”利用”を分離する

http://dev.classmethod.jp/cloud/aws/kms-admin-user/

AWS Key Management Service(KMS)の利用方法

2016/12/13 mackerelの監視のON/OFFに使用した

KMSのざっくりとした理解としては「暗号化、復号化の悩みとして『鍵を使って暗号化するのは技術的に可能』だが『鍵の保管場所』に困る」という点を解決するサービス、という理解。

AWS KMSでの暗号化/復号化の手順はclassmethodのココが分かりやすい。

一度、aws-cliで復号化まで行う(15分程度)とよく分かる。 また暗号化されたciphertextはコードに埋め込んで使用する

下記にmackarelでの暗号化、復号化の方法ですが

[ IAM ]->[ 暗号化キー(Encryption Keys) ]->[ フィルター: ]で[ アジアパシフィック(東京) ]をクリック [ MackarelAPI ]をクリックし、[ ARN ]の値をメモする。 ( 2016/12/13時点の mackarelのマスターキーは[ arn:aws:kms:ap-northeast-1:123456789012:key/12345678-1234-1234-1234-1234567890ab ]だった )

ココの方法に従い、 aws-cliで上記のarnを指定して環境変数KEYIDにarnを指定する

export KEYID=arn:aws:kms:ap-northeast-1:123456789012:key/12345678-1234-1234-1234-1234567890ab

暗号化

aws kms encrypt --key-id $KEYID --plaintext 'mackarelのAPIキー'

下記の内容が出力される

{
  "KeyId": "arn:aws:kms:ap-northeast-1:123456789012:key/12345678-1234-1234-1234-1234567890ab",
  "CiphertextBlob": "himitu"
}

CiphertextBlobをコード側で利用する。　node.jsでのコードは下記が参考になる。

ALBだけでメンテナンス画面を表示させる際の注意

Posted: 2016-08-03 | Categories: AWS | Tags: AWS, EC2

なるべくサービス側のシステムを触らずにALBだけでメンテナンス画面を出したかった

参考: FixedResponseActionConfig (ALB)

• Fixed response のメッセージボディは 1024 バイトまで

• HTML を入れる場合はサイズ制限が厳しいので、必要なら minify して縮める

• CDNキャッシュ初期化は必要なドメインすべてで行う必要がある

AWS EC2 オートスケール

Posted: 2016-08-03 | Categories: AWS | Tags: AWS, EC2

EC2のオートスケールは、EC2のWebUIの下記の要素で作成する

AMI <- ami-idを確認する
AUTO SCALING
起動設定 <- 主にEC2の起動設定、どのAMIからEC2インスタンスを作成する、spotインスタンスにするか、など。複数作成して切り替える事が可能。
Auto Scalingグループ <- 主にネットワーク周りの設定

起動設定を作ってから、AutoScalingグループを作成する。 [ AutoScalingグループ ]には「どのAMIからEC2インスタンスを作成するか」という[ 起動設定 ]を切り替えることができる。

高負荷時のオートスケールにかかる時間は5分から6分程度、EC2インスタンス起動に通常、120秒ほどかかる事を考えると、負荷の検知、スケールアウト準備、インスタンス起動、サービス開始、と妥当な時間のように思う。

が、ライブ開始前と21:00の負荷の際にはあらかじめサーバを足しておきたい。この設定は [ AutoScalingグループ ]->[ スケジュールされたアクション ]で設定可能。

※ このスケジュールされたアクションを設定する際の [ 開始時刻 ]の注意点は

デフォルトで翌日の設定になってる
一度開始時刻を設定しようとすると、CRONの設定が消えるという点が注意点。スケジュールが実行されないケースがあった。

実際にスケジュールが実行されたかどうかは[ アクティビティ履歴 ]を見ると分かる

AWS EC2メモ

Posted: 2016-08-03 | Categories: AWS | Tags: AWS, EC2

インスタンスタイプごとのネットワーク帯域

iperfなどで計測する。

iperf -c %LOCAL_IP_ADDRESS% -t 60

EC2 – EC2 間は5Gbps程度参考水門は開いた – EC2 インスタンスのネットワーク帯域幅が増大

起動時、パッケージのセットアップがうまく行かない場合

/etc/sysconfig/cloud-init の package_setupの項目をnoにする。

参考 VPC内にEC2を立ち上げようとしてcloud-initのpackage_setupでハマる

チェックポイント

EC2

余計なセキュリティグループがついてないか、つまり余計なポートが空いてないか
opsに余計なのがついてたり( port 22 が、まだ空いていたり )
AZ分散しているか?
たまに「サブネットを作ってなかった」というミスがあり、この場合、サブネットが寄ってしまっている。
opsにはEIPが割り当てられているか
パラメータストアにSLACKの値は設定しているか

ロードバランサー

port 443 でリスナーが立っているか?
『CloudFront障害』のケースを考えると、オリジン側もHTTPではなくSSLで受ける必要がある。
Deletion Protection をonにする。削除されなくするやつか

ターゲットグループ

ELBのtarget groupにおける stickness が無効になってたので30秒で有効に変更する

EC2 上に Nginx + PHP + Phalcon 構築手順

nginxの UID:GIDを揃える

下記のファイルで必要になる。 UID:GID統一の方法としては

NIS or LDAP 導入
追加するアプリのUID:GID全て統一
必要なアプリのUID:GID統一があるが、今回は3にした。基本的には『サーバ間でファイルをコピーする場合』にUID:GIDが揃ってないと、動作しないので。 ( 上場してパスワード更新が求められるようになったらldap導入するか検討しても良いかもしれない )

パッケージインストール

git インストール

yum -y install git gcc make libtool

カーネルパラメータ追加

sudo vi /etc/sysctl.conf

下記を追記

AWS アカウント関連のメモ

Posted: 2016-08-03 | Categories: AWS | Tags: AWS, AWSアカウント

[[Amazon Linuxの正体～タイムゾーン～ | サボり屋の技術メモ|https://angelndxp.wordpress.com/2012/06/25/amazon-linux%e3%81%ae%e6%ad%a3%e4%bd%93-%ef%bd%9e%e3%82%bf%e3%82%a4%e3%83%a0%e3%82%be%e3%83%bc%e3%83%b3%ef%bd%9e/]]

AWS rootアカウント

そもそも必要になるケースが少ない、ので触れる機会が少ないのでメモを残しておく

rootアカウントでしかできない作業
- AWS account root user - AWS Identity and Access Management

MFA周り

「MFAに問題があるか?」は「パスワードを変更してみてログインできるか?」で切り分けられる
rootユーザのMFAが壊れた時のログイン方法｜伊藤忠テクノソリューションズ
- 確かにMFAもハードウェアMFAなりスマホなりは壊れるので対策が必要…
  - 一連の手順の流れがあって参考になる – 電話で連絡も受け取れないケース

- 例えばスマホが壊れるケースなどが考えられる
- [AWSアカウントで多要素認証(MFA)できなくなった。電話認証も失敗した時の対処方法 - そろそろ本気を出しますか](https://that-is-nuts.com/archives/142)
- [スマホ交換したら、AWSアカウントで多要素認証(MFA)できなくなった→電話認証も失敗！ | リーマンダッシュ](https://salaryman-dash.com/2020/11/08/aws%E3%82%A2%E3%82%AB%E3%82%A6%E3%83%B3%E3%83%88%E3%81%AE%E3%83%AB%E3%83%BC%E3%83%88%E3%83%A6%E3%83%BC%E3%82%B6%E3%81%A7%E5%A4%9A%E8%A6%81%E7%B4%A0%E8%AA%8D%E8%A8%BCmfa%E3%81%A7%E3%81%8D%E3%81%AA/)

電話番号を更新する手順
- AWS アカウントの電話番号を更新する | AWS re:Post
  - 「連絡先情報」を更新する。日本だと+81もprefixで必要

オフィシャルの情報

MFA デバイスが故障または紛失した場合のセルフサービスによるリセットの方法 | Amazon Web Services ブログ
IAM 内で MFA で保護された ID を復元する - AWS Identity and Access Management
- rootと一般ユーザで手順が異なる模様
ルートユーザーに関する問題をトラブルシューティングする - AWS Identity and Access Management
- rootユーザのパスワードを忘れた等

AWSマーケットプレイスでのイメージ検索

Posted: 2016-08-03 | Categories: AWS | Tags: AWS, EC2

AMI( HDDイメージのようなもの )の選択

AMIの選択はEC2を起動する際やここから検索できるただ検索できた方が、なにかと自動化しやすい( わざわざブラウザで開かなくて良い )ので方法を残す

例えばAMI名に『KUSANAGI』を含むAMIを検索する場合

aws ec2 describe-images \
  --region ap-northeast-1 \
  --owners 'aws-marketplace' \
  --filters 'Name=name,Values=*KUSANAGI*'

例えば Amazon Linux の最新AMI IDが欲しい場合

Amazon Linux は SSM パブリックパラメータから取得する方が確実。公式: Amazon Linux 2023 の AMI を取得する

Amazon Linux 2023 (x86_64) の例:

aws ssm get-parameter \
  --region ap-northeast-1 \
  --name /aws/service/ami-amazon-linux-latest/al2023-ami-kernel-default-x86_64 \
  --query 'Parameter.Value' \
  --output text

Amazon Linux 2 など他の系列は、該当するパラメータ名を公式一覧から確認する。

プロダクトコード、オーナーで検索する場合

「あるオーナーの更に、プロダクトごとに絞り込みたい」ようなケース。

オーナーは、大雑把にいうと「Amazonが所有者のもの( amazon )」と「それ以外( aws-marketplace )」な区分がある。

AWS SNSを使う

Posted: 2015-05-20 | Categories: AWS | Tags: AWS, lambda, SNS

lambdaネタ

SNS + Lambda + Slack でアラート通知を受け取る - Qiita

障害時でもまずPush通知がされるまでの流れを把握

http://dev.classmethod.jp/cloud/aws/sns-mobile-token/ この中のフローが非常に参考になる。

大規模Push配信環境メルカリの例

ハイパフォーマンスGaurun〜メルカリの大規模プッシュ配信を支えるミドルウェア〜 - Mercari Engineering Blog

Push通知が届かない場合

http://faq.growthbeat.com/article/60-push

電源が入っていない
証明書の有効期限が切れてる
デバイスのプッシュ通知ステータスがアクティブ(Active)になっていない
アプリがアンインストールされてる
登録されているデバイストークンと環境(development/production)が一致しない

証明書の扱いは難しいらしい

http://faq.growthbeat.com/article/81-growthpush

具体的にエラーとなるのは、下記のような場合です：

iOSの証明書の有効期限が切れている

iOSの証明書が無効化されている。

AndroidのAPIキーのIP制限が設定されている

Androidの証明書が無効化されている

PHPでPush通知を実装する

http://qiita.com/toshiyuki_wada/items/a072ec557a49c6f8c00a

AWS CLIで取得する

http://qiita.com/tcsh/items/e2184f8c7c283e93b167

各メトリクスの説明

Amazon Simple Notification Service のメトリックスおよびディメンション - Amazon CloudWatch

NumberOfMessagesPublished 発行されたメッセージの数。

NumberOfNotificationsDelivered 正常に配信されたメッセージの数。

NumberOfNotificationsFailed Amazon SNS が配信に失敗したメッセージの数。
このメトリクスは、Amazon SNS が Amazon SQS、電子メール、SMS、またはモバイルプッシュのエンドポイントへのメッセージ配信の試行を停止した後に適用されます。
HTTPまたはHTTPSエンドポイントに対して配信が試行されるたびに、メトリクスが1つ追加されます。
他のすべてのエンドポイントの場合、メッセージが配信されないとカウントが1増加します (試行回数に関係なく)。
HTTP エンドポイントの再試行の数は制御できます。詳細については、「HTTP/HTTPS エンドポイントに対する Amazon SNS 配信再試行ポリシーの設定」を参照してください。

AWS CLI でトピックを作成する

aws sns create-topic --name test_20150715 --region ap-northeast-1

出力例:

Tag: AWS

チャンネル操作

セキュリティグループの雛形を得る

作成

削除

push までの流れ

アップデート手順

システム構成

事前のステージング環境での確認

本番での作業の流れ

RDS のスナップショットから DB 作成

nuxt用の設定についてまとめた

オリジンとCDNの関係

1. ALBで、FQDNで正しいターゲットグループに振り分けられる用に設定する

CloudFront設定

Behaviors を追加する

Canvas LMS の起動に時間がかかりすぎて Passenger が落ちる

環境

原因

仕組み

EC2 上で自分自身のイメージを取得するスクリプトを用意する

EC2 の IAM ロールで AMI 化を実行するのに必要な権限を付与する

EC2 サーバの crontab にスクリプトを用意する

背景

ALBのログを解析する

ログのステータスコードの意味

作業の流れ

実作業

VPC作成

手順

ログイン

組織を作成する

アカウント( というかOrganization のアカウント )の作成

アカウント( というかOrganization のアカウント )の情報入力

Organizationをアクティベートする

ログ取得

クエリ(フィルタリング)について

クエリ例

nginxのログのみを表示する

ロードバランサからのヘルスチェックを除外する

ステータスコードが500番台のもののみを表示する

ログをパースして変数にセットする

クエリ実行( ログ検索は時間がかかるため、後で別途getする必要があります)

背景

手順

WebUI

SNS トピック作成

CloudWatch

CLI

CloudWatchのアラートを設定する方法

alarms.sh

使い方

alarm_mem_template.json

alarm_cpu_template.json

手順

バックアップを取得する( m3インスタンス以上でないとバックアップは取れない模様。t2で検証したが取れなかった )

バックアップから復元する

動作確認

キーが帰ってくるか

目的

作りたいシステム構成

感想

背景

AWS メディアサービスって?(複数サービスの集合でした)

設定方法

MediaLive について

CodeBuildで設定した方が良さそう環境変数リスト

ECRのタグ( buildspec内でdocker pushしている )ポリシー

開発用のECSタスク定義で使用するDockerイメージには dev のタグをつける

CodeBuildの設定を複製する

既存の設定情報を取得する

取得したjsonファイルを修正する

反映

replicaが高負荷になった

AWS_RDS_Aurora_監査ログ取得のための変更

パラメーターグループ

作る

編集

反映

パラメータグループ作成

開発用のECSタスク定義で使用するDockerイメージには `dev` のタグをつける

障害時でもまずPush通知がされるまでの流れを把握

大規模Push配信環境メルカリの例