AWS re:Postを使用することにより、以下に同意したことになります 利用規約

タグ付けされた質問 Amazon EC2

コンテンツの言語: 日本語

並べ替え 最新

以下に記載されている質問と回答を閲覧したり、フィルタリングして並べ替えて結果を絞り込んだりできます。

EC2インスタンス内からリージョンコードを取得する方法

いつもお世話になっております。 EC2インスタンス内で動作するアプリケーションで、アプリケーションが動作している インスタンスが属するリージョンコードを取得したいと考えております。 AWSのマニュアルを確認したところ、直接リージョンコードを取得する方法が見つからなかったので、 以下のような方法でリージョンコードを取得しようと考えております。 =============================================================== ①インスタンスメタデータ取得URIにてアベイラビリティーゾーンを取得する。  URI:http://169.254.169.254/latest/meta-data/placement/availability-zone  参考URL:<https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/instancedata-data-retrieval.html> ②取得したアベイラビリティーゾーンの文字識別子(右端の1文字)を除いた値をリージョンコードとする。  例)アベイラビリティーゾーン:ap-northeast-1c    ↓ 右端の1文字「c」を除く   リージョンコード:ap-northeast-1  参考URL:<https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/using-regions-availability-zones.html#concepts-availability-zones> =============================================================== リージョンコードの取得方法として、上記の方法で問題ありませんでしょうか? アベイラビリティゾーンの文字識別子を1文字と想定しており、この想定に問題がないかを気にしております。 上記の方法で問題がある場合、リージョンコードを取得する他の方法をご教授していただけますでしょうか? お忙しいところ恐縮ですが、何卒よろしくお願いいたします。
2
回答
0
投票
5
ビュー
質問済み 2年前

EBS性能がカタログスペック値と異なる原因と改善策

独自のカラムナーDBを構築しようとしております。 独自のカラムナーではカラムごとにファイルが作成されるため、ファイルサイズが大きくなり、 読み書きの性能が重要です。一方でコストもなるべく安く抑えたいため、どのタイプのEBSが 最適であるか、性能評価しております。 性能評価の結果、仕様値よりも高性能なケース、低性能なケースを確認しました。 下記の点について、教えていただけないでしょうか。 ★1:スループット最適化HDD(st1)が低性能となる原因、改善策   (カタログスペック値 500MB/s のスループットが欲しい) ★2:マグネティック(standard)をルートボリュームとした場合に    スループット最適化HDD(st1)と同等の高性能となる理由 ★3:プロビジョンド IOPS SSD (io1)が低性能となる原因、改善策   (カタログスペック値 1000MB/s のスループットが欲しい) ■性能評価結果 READ(32MB Block シーケンシャルリード)  HDD(st1)   ( 追加ボリューム) 364 MB/s ★1 仕様よりも低性能  HDD(sc1)   ( 追加ボリューム) 174 MB/s  HDD(standard)( 追加ボリューム)  57 MB/s  HDD(standard)(ルートボリューム) 347 MB/s ★2 仕様よりも高性能  SSD(gp2)   (ルートボリューム) 265 MB/s  SSD(io1)   ( 追加ボリューム) 364 MB/s ★3 仕様よりも低性能  SSD(io1)   (ルートボリューム) 356 MB/s ★3 仕様よりも低性能 WRITE(32MB Block ランダムライト)  HDD(st1)   ( 追加ボリューム) 325 MB/s ★1 仕様よりも低性能  HDD(sc1)   ( 追加ボリューム) 160 MB/s  HDD(standard)( 追加ボリューム)  54 MB/s  HDD(standard)(ルートボリューム) 345 MB/s ★2 仕様よりも高性能  SSD(gp2)   (ルートボリューム) 265 MB/s  SSD(io1)   ( 追加ボリューム) 357 MB/s ★3 仕様よりも低性能  SSD(io1)   (ルートボリューム) 357 MB/s ★3 仕様よりも低性能 ■公式ページに記載された最大スループット  汎用 SSD (gp2)          250 MiB/s  プロビジョンド IOPS SSD (io1)  1,000 MiB/s ★3  スループット最適化 HDD (st1)   500 MiB/s ★1  マグネティック(standard)    40~90 MiB/s ★2 https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ebs-volume-types.html#ebs-volume-characteristics https://aws.amazon.com/jp/ebs/previous-generation/ ■性能評価した環境&設定  リージョン:   東京  EC2インスタンスタイプ:   r5a.2xlarge    →8コア、64GBメモリ    →EBS最適化あり  AMI:   Amazon Linux 2 AMI (HVM), SSD Volume Type 64bit(x86)   (Amazon Linux 2 AMI 2.0.20200207.1 x86_64 HVM gp2)  ボリュームサイズ:   全て 1000 GiB  ファイルシステム:   XFS    →ルートボリュームは、インスタンス作成時のまま変更なし    →追加ボリュームは、mkfs -t xfs /dev/xxx でフォーマット。オプションなしでマウント。  ベンチマークツール:   fio  ベンチマーク共通パラメータ:   スレッド数  : 8   ダイレクトIO : true   データサイズ : 70GB   ブロックサイズ: 32MB   テスト時間  : 30秒 下記の投稿も確認したのですが、仕様よりも高性能となる原因ということで新たに投稿させていただきました。 https://forums.aws.amazon.com/thread.jspa?messageID=404960&#404960; よろしくお願いいたします。 Edited by: shimbara on Mar 27, 2020 2:37 AM
1
回答
0
投票
5
ビュー
質問済み 3年前

EC2側のCA証明書の設定を変更していないにも関わらず、RDS側に対してSSL接続が行われている理由

お世話になっております。 RDSの証明書設定変更に関して不明点があるため、ご相談させていただきます 現状は、RDSの証明書の設定変更が完了してこれまで通り疎通はできているのですが、プラットフォームの理解が不足しており、3月5日以降も正しく動作するという確証が持てない状況です。 詳細は以下の通りです ■システムの構成 EC2(AmazonLinux)・RDS(PostgreSQL) EC2とRDSは、同一VPC・同一セキュリティグループ内に存在 ■現状 ・公式ドキュメント等を参考にRDSの設定を2019年版の証明書に変更し、RDSの再起動を行って設定変更の適用が完了している https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/ssl-certificate-rotation-postgresql.html ・RDSの設定変更後に、以下の3つの方法で、SSL接続ができている事を確認済 ・・アプリケーションを操作してDBに接続されている事を確認 ・・EC2インスタンスからpsqlで接続した場合もSSL接続される事を確認 ・・以下を参考に、pg_stat_ssl・pg_stat_activityでも、SSLで接続されている事を確認 https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/ssl-certificate-rotation-postgresql.html#ssl-certificate-rotation-postgresql.determining-server ■不明点・不安点 ・今回のRDSの設定変更において、EC2側のCA証明書の設定変更などは一切行っていない ・アプリケーション側の設定や、EC2インスタンス上のCA証明書に関する設定は調べた限りではない(ただしアプリケーションの開発およびAWSの設定をした開発担当者はいないため、未知の設定が存在する可能性はゼロではない) 上記による可能性としては以下の2通りの解釈が可能だと思っています。 ①同一VPCのセキュリティグループにあるRDSに対しては、内部的に自動でSSLによる接続が行われる仕様となっている。そのためSSLの接続情報や証明書がなくてもSSL接続となる ②RDSの設定変更後も、依然として何らかの未知の接続情報が有効になっており、3/5以降に接続が無効となる ①に該当するドキュメントが見当たらなかったため推測の域を出ておらず、②の可能性が排除できないです。 そのため作業を完了とみなして良いのか判断できず困っております。 ご教示いただけると幸いです Edited by: tunemage on Jan 20, 2020 10:21 PM
2
回答
0
投票
5
ビュー
質問済み 3年前

今週からCloudFormationのRest APIが"Signature expired:"と言い出しました

こちらでは初めまして、showkkoと申します。 先週はうまくいっていたCloudFormationへのAPIリクエストが、今週に入ってうまくいかなくなりました。 返答は「SignatureDoesNotMatch」なのですが、その内容が === Signature expired: 20200110T064809Z is now earlier than <5分前> (<今> - 5 min.) === で、この「20200110T064809Z」は何故か固定なんです。 SignatureはVersion 2で作っており、Python 3で書くと以下のような感じです。 === timestr=urllib.parse.quote_plus(datetime.utcnow().strftime("%Y-%m-%dT%H:%M:%SZ")) sig_data="POST\ncloudformation.ap-northeast-1.amazonaws.com\n/\nAWSAccessKeyId="accessid"&Action=DescribeStackResources&SignatureMethod=HmacSHA256&SignatureVersion=2&StackName="_stackname_"&Timestamp="timestr"&Version=2010-05-15" sig_seed=hmac.new(secretkey.encode("utf-8"),sig_data.encode("utf-8"),hashlib.sha256) signature=urllib.parse.quote_plus(base64.b64encode(sig_seed.digest()).decode("utf-8")) === 上記のようにグリニッジ標準時を取得して生成しており、少なくとも毎回「20200110T064809Z」という固定の日時で蹴られることはない筈なんですが…。 (変換前の文字列を出力して確認していますので、時間がおかしいことはない筈です。) 同様のコードでEC2ではうまくいきます。また、CloudFormationでも先週はうまくいっていました。 どなたか原因は想像つきますでしょうか?
1
回答
0
投票
1
ビュー
showkko
質問済み 3年前

サーバーダウン復旧後にCPU負荷が急に上がってしまいました

EC2インスタンスを使ってWEBサービスを運用しているのですが、先日、10分ほどサーバーダウンが起きて自動復旧した直後からCPU負荷が異常に高くなっていて、普段の2倍近くになってしまいました。以前は20~40%くらいのCPU負荷だったものが、現在は60~100%を推移しています。 アクセス数やDBの負荷(DBは別サーバー)も確認したのですが、そちらは以前と同じくらいでした。 【インスタンス情報】 インスタンスタイプ: c3.2xlarge アベイラビリティーゾーン: ap-northeast-1c vCPU の数: 8 サーバーダウン前していたことといえば、その6時間前くらいにCloudFrontのBehaviorのWhitelist Headersを変更したくらいで、直近ではインスタンス自体への操作は特に行っていませんでした。 ただこのCloudFrontの設定変更もサーバーの負荷を上げるようなものではないと思っています。 プロセスを確認してみると、負荷の高いプロセスはApacheのものでCPU使用率が10~50%のプロセスが10個以上動いていました。 それ以外のプロセスは負荷が高いものは無いようでした。おそらく、Apacheが重くなっているようです。 再起動後にCPU負荷が急増するという現象の原因に心当たりのある方いらっしゃいませんでしょうか? あと、そもそもEC2インスタンスが10分間も停止するようなことがあるのでしょうか? よろしくお願いします。
1
回答
0
投票
2
ビュー
kimoto
質問済み 3年前