kasei_sanのブログ

かせいさんのIT系のおぼえがきです。胡乱の方はnoteとtwitterへ

RDS の Aurora の昇格についておぼえがき

RDS AWS Terraform

RDS Auroraでライターインスタンスが死んだ場合、どういうルールで昇格するんだっけ?

  • ライターインスタンスの内「優先度」が最も低い値のインスタンスから選ばれる(0がデフォルト)
  • 同じ「優先度」の場合、同じサブネット、AZのものが優先される

Terraformでインスタンスの「優先度」を決めるにはどうしたら良いの?

instances の中で promotion_tier を設定すれば良い

  instances = {
    1 = {
      # 未指定だと 0
      instance_class      = "db.r5.2xlarge"
      publicly_accessible = true
    }
    2 = {
      identifier     = "static-member-1"
      instance_class = "db.r5.2xlarge"
      promotion_tier = 10
    }
    3 = {
      identifier     = "excluded-member-1"
      instance_class = "db.r5.large"
      promotion_tier = 15
    }
  }

typeが READER のカスタムエンドポイント内のリーダーインスタンスが昇格するとどうなるの?

  • エンドポイントから外される
  • なので、負荷がギリギリなカスタムエンドポイントだと死ぬ
  • そういうエンドポイントのインスタンスは、優先度の数値を高くして昇格を防ぐ

フェイルオーバーや昇格に伴って DB インスタンスのロールがライターとリーダーの間で変更されると、Aurora は静的リストまたは除外リストで指定された DB インスタンスを変更します。

例えば、タイプ READER のカスタムエンドポイントに Aurora レプリカが含まれ、その後、ライターインスタンスに昇格されたとします。新しいライターインスタンスは、カスタムエンドポイントの一部ではなくなります。

docs.aws.amazon.com

👆ここの「カスタムエンドポイントのメンバーシップルール」より

参考

registry.terraform.io

dev.classmethod.jp

GitHubのRSA SSH ホスト鍵変更に対してクライアント側の修正方法

GitHub SSH Linux

GitHubのRSA SSH 秘密鍵が漏洩したため、2023/03/24 にGitHubのRSA SSH ホスト鍵が変更されました

github.blog

RSA SSH 秘密鍵って?

  • RSAは暗号化方式
  • RSA SSH 秘密鍵は、RSAでSSHするためにGitHubが持っている秘密鍵
  • 今回これが漏洩した

RSA SSH ホスト鍵って?

  • 秘密鍵と公開鍵のペアのこと
  • クライアント側は、接続するサーバから公開鍵を受け取って known_hosts に格納する
  • known_hosts に鍵が格納されると、次回以降のSSH接続では、known_hosts にある公開鍵と、サーバから受け取る公開鍵に差異が無いことを確認して、サーバが偽物に成り代わっていないかチェックするようになる

ホスト鍵が変わると何が困るの?

ホスト鍵(公開鍵も)が変わり、known_hosts にある GitHub の公開鍵と、GitHub受け取る公開鍵に差異が発生するため、SSH接続が失敗するようになる

具体的にはこんなエラーが出る

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
d5:2c:63:d9:bc:75:9d:de:b1:4e:36:28:9f:7a:9c:39.
Please contact your system administrator.
Add correct host key in /home/hoge/.ssh/known_hosts to get rid of this message.
Offending RSA key in /home/hoge/.ssh/known_hosts:3
RSA host key for github.com has changed and you have requested strict checking.
Host key verification failed.

👆/home/hoge/.ssh/known_hosts の3行目にある公開鍵と、サーバから受け取った公開鍵が違うよというエラーメッセージ

どうしたら良いの?

公式ドキュメントの手順に従えばOK

known_hosts から古い公開鍵を削除

ssh-keygen -f /home/hoge/.ssh/known_hosts -R github.com

👆github.com に関する known_hosts の情報を削除するよというコマンド

known_hosts に手動で以下の公開鍵を追加

github.com ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQCj7ndNxQowgcQnjshcLrqPEiiphnt+VTTvDP6mHBL9j1aNUkY4Ue1gvwnGLVlOhGeYrnZaMgRK6+PKCUXaDbC7qtbW8gIkhL7aGCsOr/C56SJMy/BCZfxd1nWzAOxSDPgVsmerOBYfNqltV9/hWCqBywINIR+5dIg6JTJ72pcEpEjcYgXkE2YEFXV1JHnsKgbLWNlhScqb2UmyRkQyytRLtL+38TGxkxCflmO+5Z8CSSNY7GidjMIZ7Q4zMjA2n1nGrlTDkzwDCsw+wqFPGQA179cnfGWOWRVruj16z6XyvxvjJwbz0wQZ75XK5tKSb7FNyeIEs4TT4jk+S4dhPeAUC5y+bDYirYgM4GC7uEnztnZyaVWQ7B381AK4Qdrwt51ZqExKbQpTUNn+EjqoTwvqNj4kqx5QUCI0ThS/YkOxJCXmPUWZbhjpCg56i+2aB6CmK2JGhn57K5mj0MNdBXA4/WnwH6XoPWJzK5Nyu2zB3nAZp+S5hpQs+p1vN1/wsjk=

実際に GitHub に SSH して動作確認する

$ ssh -T git@github.com

Warning: Permanently added the RSA host key for IP address '20.27.177.113' to the list of known hosts.
Hi hoge! You've successfully authenticated, but GitHub does not provide shell access.

警告が出なければOK

ウチのサーバの場合、さらに以下の警告も出たので同様に公開鍵を削除した

Warning: the ECDSA host key for 'github.com' differs from the key for the IP address '20.27.177.113'
ssh-keygen -R 20.27.177.113

参考

SSH公開鍵については、過去のblog記事で解説してます

kasei-san.hatenadiary.org

AWS コスト削減チェックリスト

AWS EC2 ECS S3 lambda

前提

  • 金銭的なコスト削減のために、運用コストが上昇したら元も子もないので注意!!!

全体

  • EC2 から、ECS(Fargate)、lambdaへの移行を検討中ならば、Compute Savings Plansを使用する
  • そもそも使っていないインスタンスを停止する

EC2

  • 性能が過剰ならば、より低スペックのインスタンスに変更する
  • インスタンスタイプが古いのであれば、最新にする(最新のほうが安い
  • 可能であれば、CPUを Graviton に変更する
  • 24H稼働が不要であれば、夜間休日は停止する(検証環境や営業時間しか使わないサービスなど)
  • 停止しても問題なければ、スポットインスタンスに変更する
  • 1年以上使用するのであれば、リザーブドインスタンスやSavings Plansを契約する
  • バッチ処理などは、ECS(fargate)やlambdaへの移行を検討する
    • → そもそもEC2は運用コストが高い場合が多い
  • オートスケーリンググループを使って、低負荷時はマシンを停止する

ECS(fargate)

  • 性能が過剰ならば、メモリやCPUを減らす
  • 可能であれば、CPUを Graviton に変更する
  • 24H稼働が不要であれば、夜間休日は停止する(検証環境や営業時間しか使わないサービスなど)
  • 停止しても問題なければ、Fargate Spotに変更する
  • 稼働する量が決まっているならば、Savings Plansを契約する
  • 処理頻度が低いのであれば、lambdaに移行する

RDS(Aurora)

  • 性能が過剰ならば、インスタンスタイプを下げる
  • CPUを Graviton に変更する
  • 低頻度アクセスや社内利用であれば、Aurora Serverlessへ移行する
  • 1年以上使用するのであれば、リザーブドインスタンスやSavings Plansを契約する
  • 不要ならばバックアップ保持期間を短くする
  • IOが多いならば、Aurora I/O 最適化を検討する

lambda

  • メモリ使用量が過剰ならば減らす → Lambda Power Tuning
  • 可能であれば、CPUを Graviton に変更する
  • 実行可否をlambda内で処理しているのならば、イベントフィルタリングを使ってlambdaを実行させないようにする
  • 実行頻度が高いのであれば、ECS(fargate)に移行したほうが安いかも

S3

  • 不要なのに保存しているオブジェクトを廃棄する
    • もしくは、数ヶ月経過後はアーカイブする
  • 消えても大きく問題がないオブジェクトは、シングルAZに変更する
  • アクセス頻度が低いオブジェクトは、低頻度アクセスやアーカイブに変更する
  • S3Intelligent-Tieringを使って自動的にコスト最適化を行う

PostgreSQLでのdump、restore、COPYおぼえがき

postgresql Aurora

データベースの dump

pg_dump -d ${dbname}  > /var/tmp/dbname.dump

特定のテーブルのみ dump

pg_dump -d ${dbname} -t ${tablename}  > /var/tmp/dbname.dump

特定のテーブル 以外を dump

pg_dump -d ${dbname} -T ${tablename}  > /var/tmp/dbname.dump

データベースのリストア

pg_restore -d ${dbname} --jobs8  /var/tmp/dbname.dump
  • jobs オプションは、indexの作成などを複数ジョブで実行するためのコマンド。CPUの数以内にする

上記の場合、dumpファイルにDBの削除/生成の命令は入らないので、リストア前に手動でDBを削除/生成する必要がある

COPYコマンドを使って、データの一部だけdump,restoreする方法

データのdump

COPY  (SELECT * FROM ${table_name} WHERE id > 123456789) TO '/var/tmp/tablename.dump';

データのrestore

COPY  (SELECT * FROM ${table_name} WHERE id > 123456789) FROM '/var/tmp/tablename.dump';
  • テーブルは生成されないので、先に以下のコマンドでdump/restoreしておく

テーブルのスキーマのみdumpする方法

pg_dump -d idoudb --no-acl -t ${table_name} -s > /var/tmp/table_name_schema.sql

Aurora PostgreSQLにCOPYコマンドでrestoreする方法

Auroraにはファイルを置けないので、標準入力を使う

cat /var/tmp/tablename.dump | psql -c "COPY tablename FROM STDIN"

参考

最近のかせいさんの情報収集方法 2021年版

この記事はLCL Advent Calendar 2021 - 18日目です。

qiita.com

こんにちは、 id:kasei_san です。

皆さん、技術情報の情報収集どうしてますか?

昔はLiveDoorReaderとか、はてなブックマークとかで集めれば割と良かったのですが、RSSがオワコンになり、はてなブックマークも(個人的には)ノイズが多くて使いづらくなってしまい、どうしたものかと考えています。

今回は、かせいさんの試行錯誤中の情報収集方法を晒して「みんなどうしてる?」という意見を伺いたくて、記事を書いてみました。

なので、「自分はこうしてるよ!」とか「こうしたらどう?」とかあったら、コメントなりはてブなり、引用RTなりで何かフィードバックいただけると嬉しいです。

それではどうぞ

概要

だいたいこんな感じで、AWSやRuby/Railsをメインに情報を収集しています。後でそれぞれの詳細について解説しますね

  • なんやかんやでRSS
  • twitter
  • ruby-jpのSlackワークスペース
  • オハヨーAWS

なんやかんやでRSS

なんやかんやでまだ生き続けているRSSも購読しています。

重要度が低いものは、feedly で暇な時にチェックして、 重要度が高いものは、slackの自分の分報チャンネルに出るようにしています

slack に出るようにしているRSS

feedly で見ているRSS

twitter

速報性ではなんやかんやここが一番ですね。 自分のやっている分野の本を書いたり、アウトプットを良くしている人、AWSの中の人などを 350人ほどフォローして います。 AWS障害とか、最近だとLog4Shellみたいな大きなできごとがあると、話題が何度も上がってくるので、見落としが無いのが良いですね。

仕方ないですね!

ruby-jpのSlackワークスペース

ruby-jp.github.io

こちらも速報性は高いです。Ruby以外にも、AWSの障害やセキュリティインシデントなども話題になるので、Rubyのwebエンジニアやっていて必要なニュースは割とここでキャッチアップできます。あと、Rubyで開発している企業blogの更新を通知してくれるチャンネルもあるので、ここでの情報キャッチアップもなかなか良いです。(弊社LCLも参加しています!)

オハヨーAWS

twitter.com

AWSの中の人などがやっている、毎朝平日9時に開かれる twitter スペースです。前日に更新された内容を30分ですごい勢いでキャッチアップしてくれるのを仕事をしながら聞いています。各サービスについてどういう場合に使うものなのかとか、マイナーなサービスの場合、これはどういうものなのかも解説してくれるので、単に更新を見るよりも理解しやすくて、助かっています。

まとめ

現状はだいたいこんな感じで、Ruby/Rails/AWSの情報を集めています。収集先が多すぎても見なくなってしまいますし、少なすぎてもキャッチアップしきれないのでなかなかバランスが難しいですね。RSS以降の世代の人はどんな風に情報収集しているのか気になっています。ぜひ「自分はこうしているよ」とかありましたら教えていただければ幸いです。

それでは!

Access-Control-Allow-Origin の値を動的に設定するときには、Vary 'Origin' も設定する必要があるよって話

http セキュリティ Nginx

これの続き

blog.kasei-san.com

Access-Control-Allow-Origin の値を動的に設定する必要があるパターン

複数のオリジンからクロスドメインのリクエストを受けるサーバが Access-Control-Allow-Origin を返す場合、オリジンごとに異なる値を動的に返す必要がある。

  • 参考: Nginxの場合のこんな感じの設定を書く

gist.github.com

その場合、CDNが問題になる

途中にCDNが挟まってる場合、Access-Control-Allow-Originが、最初に来たオリジンのままで固定されてしまう。

これにより、Access-Control-Allow-Originの値と異なるオリジンからのリクエストがすべて、CORSエラーになってしまう。

その対策

レスポンスヘッダに Vary 'Origin' を追加する。

Vary とは?

キャッシュ時にURL以外に、キーとなるリクエストヘッダの値を決める設定。 例えば Vary : Accept-Language とすると、同じURLでも、言語ごとにキャッシュされるようになる。

んで、Vary 'Origin' の場合、Origin がキーになる。 Origin は、クロスドメインのリクエストを投げた場合に、元々のドメインが格納されるリクエストヘッダ。

そうすれば、複数オリジンからのリクエストごとに、異なる Access-Control-Allow-Origin を返すレスポンスをそれぞれキャッシュできる。

参考

developer.mozilla.org

developer.mozilla.org

developer.mozilla.org

Access-Control-Allow-Origin の値が ("*" ワイルドカードではなく) 具体的なオリジンであるレスポンスをサーバーが送信する場合、レスポンスには Vary レスポンスヘッダーに Origin という値を設定して、 Origin リクエストヘッダーの値によって値が変わることをブラウザーに対して示してください。