winds.from.oz 技術メモ

Tag: AWS

redisのスケールダウン手順

Posted:   |   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 Read more...

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

Posted:   |   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 だけで完結できるか? Read more...

aws/codebuild

Posted:   |   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 のタグをつける イメージに対しては必ずタグをつける( タグがないイメージにアクセスしにくいので、実質的にバックアップの意味にもならない。 Read more...

aws/codebuildで設定を複製する

Posted:   |   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 Read more...

aws/rds

Posted:   |   Categories: AWS   |   Tags: AWS, RDS

2017/07/18 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 インスタンスのサイズやクラスによって異なり、数秒から数分になります。 結構ばらつきがあるのに注意が必要だ。 Read more...

cheetsheet/aws/rds

Posted:   |   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. Read more...

ARN、AWSのリソースの命名規則のメモ

Posted:   |   Categories: AWS   |   Tags: ARN, AWS

このページに命名規則が載っている Amazon ElastiCache 構文: arn:aws:elasticache:region:account-id:resourcetype:resourcename 例: arn:aws:elasticache:us-west-2:123456789012:cluster:myCluster arn:aws:elasticache:us-west-2:123456789012:snapshot:mySnapshot Read more...

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

Posted:   |   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:139332511982:key/3121367a-6009-493d-b3f1-05aa01a9c3f7 ]だった ) ココの方法に従い、 aws-cliで上記のarnを指定して環境変数KEYIDにarnを指定する $ export KEYID=arn:aws:kms:ap-northeast-1:1111111111111111111:key/3121367a-6009-493d-b3f1-05aa01a9c3f7 暗号化 $ aws kms encrypt --key-id $KEYID --plaintext 'mackarelのAPIキー' 下記の内容が出力される { "KeyId": "arn:aws:kms:ap-northeast-1:111111:key/3121367a-6009-493d-b3f1-05aa01a9c3f7", "CiphertextBlob": "himitu" } CiphertextBlobをコード側で利用する。　node. Read more...

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

Posted:   |   Categories: AWS   |   Tags: AWS, EC2

なるべくサービス側のシステムを触らずにALBだけでメンテナンス画面を出したかった • htmlのサイズは1024バイトまで • htmlとcssに分離する必要がある • メンテナンス画面でもhtmlが1024バイト超えている場合 http://kangax.github.io/html-minifier/ でコンパクトにした • CDNキャッシュ初期化は必要なドメインすべてで行う必要がある Read more...

AWS EC2 オートスケール

Posted:   |   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の設定が消える という点が注意点。スケジュールが実行されないケースがあった。 実際にスケジュールが実行されたかどうかは[ アクティビティ履歴 ]を見ると分かる Read more...