2&>1

AWSとかGCPとかGolangとかとか

AWS コスト削減のポイント（自分流）

クラウドのいいとこは使った分だけっていうのはあるけど使った分はしっかり請求されます。

なるべく抑えましょう

コストタグをつける

現状を把握が必要です。 どのリソースがどのくらい費用がかかっているかCost Explorerで明らかにしましょう。 以前はコストタグを付けたときからの費用計算しかできなかったのでしばらく待つ必要ありましたが、最近のアップデートで12ヶ月遡って計算してくれるようになりました。

AWS コスト配分タグが遡及適用のサポートを開始

リザーブドインスタンス、savingplanの活用

基本の木です。EC2はもちろんECS,lambdaも対象になるのでインスタンス立ち上げぱなしの環境はまず購入。 savingplanに関しては7日以内のキャンセルが可能なので購入時のボタンを押す緊張感が若干なくなりました。

AWS が Savings Plans の 7 日間の返品期間と発表

これで一番恩恵を感じられるのはRDSやopenserch serviceじゃないでしょうか。 ただでさえ高いですからその分割引された金額が安く感じます。（ServerlessはRIないので注意） RIだとインスタンススペックの柔軟性がなくなるのがきついなーって場合はあるとおもいます。同じインスタンスタイプ内でスペックを１つ上げる場合は購入したRIは適応されるので損にはならないです。 １つ下げるときは購入した半分は未適応状態になるのでちょっと損です。

インスタンスを夜間停止する

ステージング環境など業務時間だけ触って夜間は触らないような環境は停止したほうが安い場合が多いです。8時起動→20時停止など稼働率50％だとRI契約は高くつきます。 EventBrigeで自動停止・自動起動させるようにしましょう。RDS、ECSなどもできるので忘れずに。

EventBridgeスケジューラを使ってEC2の定期起動/停止を行う方法 | DevelopersIO

スペックの最適化

使用リソースに基づいて各インスタンスのスペックを決めましょう。え？難しい？「AWS Compute Optimizer」に任せましょう。いい感じにしてくれます。 このサービスメモリをデフォルトで見てくれないの改善しないかなぁ。。 古いインスタンスタイプを使用している場合は、最新の同じインスタンススペックに変更するだけで安くなります。 ECSのスペック決めは課題が残る。。

お金のかかる不要リソース削除

「Elastic IP」「ELB」検証だけで立てたものがそのまま残ってる場合が多々あります。こまめに削除しましょう。 Elastic IPも１つづつ課金させるようになってるので注意です。

スナップショットなど数年前に作成したもの残ってないですか？そんなもので今リソースを再構築することないので消しましょう。

ここまでは即効性のある対策。ここからはちょっと手間がかかるかも。

ECSログの吐き出し先

ECSからログの出し方はいくつかありますが一番シンプルで楽なのがCloudwatch logsに出す方法です。しかしログの量によってはとてつもない費用がかかるのがCloudwatch logs。

保管費用もよりも吐き出したときにかかる費用が高いです。東京リージョンでUSD0.76/GBもかかります。

Cloudwatch logsはログ監視もできて便利ですが吐き出すログは取捨選択しましょう。

おすすめはエラーログだけCloudwatch logsに出してそれ以外はS3に放り投げる。

Cloudwatch のメトリクス設定しすぎない

Cloudwatchの監視は標準メトリクスの他にカスタムメトリクスを作って監視項目を設定できます（メモリ監視みたいなの）

カスタムメトリクスの場合無料枠が10個まででそれ以上は監視するたびに費用が発生します。何も考えずにあれこれと数字だけ取ることを目的とした設定をしていると合算したとき高くつくときがあります。ある程度まとまらないとわからない点など注意です。 監視が必要な値に絞りましょう。

まとめ

もともと高いサービスは注意が行きやすいけど、合算したとき人知れず高くなるものは注意が必要ですね。

円安な今気をつけましょう。。

Akamai構成のKeepAlive設定を決めた

AkamaiCDNが前段にあるシステムで後ろに控えるALBやApacheのKeepAlive設定を検証しました。

さらには先日リリースされた以下機能でALBに追加された項目を確認。

aws.amazon.com

項目名は以下の2つが関連する。

「Connection idle timeout」

「HTTP client keepalive duration」

項目の意味合いとしはこんな感じ

実際にはどのような挙動になるのかを確認する

Connection idle timeout

ClientとTargetに対してidle状態（無通信状態）でコネクションを保持する時間

HTTP client keepalive duration

Clientに対してのkeepalive時間

（この時間だけはなにがあろうとコネクションを残しておくということ）

確認手順

ALBに対してtelnetでアクセス

 telnet test-local-frt-alb01-1038675640.ap-northeast-1.elb.amazonaws.com 80
telnet test-local-frt-alb01-1038675640.ap-northeast-1.elb.amazonaws.com 80
Trying 54.95.144.247...
Connected to test-local-frt-alb01-1038675640.ap-northeast-1.elb.amazonaws.com.
Escape character is '^]'.
GET / HTTP/1.1    　←入力
Host: localhost　　←入力
　　　　　　　　　←エンター入力
HTTP/1.1 200 OK
Date: Tue, 09 Apr 2024 01:26:24 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 12
Connection: keep-alive
Server: Apache/2.4.58 (Amazon Linux)
Last-Modified: Mon, 08 Apr 2024 09:24:32 GMT
ETag: "c-615925f82a5c5"
Accept-Ranges: bytes

test server

「test server」の表示でるとHTTPアクセス成功

「Connection closed by foreign host.」 の表示が出るまでは同じコネクションで通信していることになる

設定値は以下

確認１

初回アクセスから２０秒放置すると「Connection closed by foreign host.」が出力されて切断

確認２

初回アクセスから６０秒放置しても切断されず。 １２０秒放置すると「Connection closed by foreign host.」が出力されて切断

６０秒以降１２０秒までの間にアクセスするとステータス成功した後「Connection closed by foreign host.」が出力されて切断

結果

「Connection idle timeout」は強制的に切断される

「HTTP client keepalive duration」は強制切断はされない

Apache側のkeepaliv値により違いはクライアント側の挙動では確認できず。

ただしALB-Apache間ではコネクションの切断再接続は起きていると想像。

（パケットキャプチャーなどでみると都度都度コネクションの張り直しが発生しているはず）

Akamai含めての設定値

セオリーとしては前段システムのkeepaliveは長く、後ろは短く。

後ろが長いと後ろ側だけ成功してて前には失敗が返ってしまう可能性があるため。

今回はAkamaiでの処理を最優先で発揮させるためにakamai-alb間のコネクションを最大限つなげる

ALBでのHTTPステータスコードとTargetでのHTTPステータスコードを監視しておくことでkeepaliveによる返り値の違いを把握できる。

Akamai Community

Organizationsな組織アカウントでCloudwatchグラフを共有したいときにできなかったこと

やりたいこと

モニタリングアカウントを用意して監視を集約したい。 Cloudwatchグラフを作成してモニタリングアカウント経由で組織アカウントのだれでもサクッと見れるようにしたい。

やり方

具体的な設定方法はよくあるものなので以下とか参考に

[Organizations]CloudWatchを別アカウントに共有する際にOrganization account selectorを使ってみた | DevelopersIO

なにができないの？

この設定をしたときに設定したアカウント以外から見たときにグラフの選択肢が出てこなかったのです。

具体的にはここ

他のアカウントからはアカウントの一覧を選択する欄が表示されなかった。

原因

モニタリングアカウントのCloudwatch設定で「アカウントセレクタを有効化」する項目がデフォルトだと何も選択されいない状態だったため

でもこれ設定したアカウントで有効化したんですよ。

どうやらこれはログインしているアカウントユーザー毎の設定でした。 （サポート確認済み）

だから各ユーザー毎に有効化しないといけないです。

どうしたのか

理想としては各ユーザー毎の作業必要なく見れるのがベストです。（無用な問い合わせを避けるためにも）

各アカウントでパブリックなcloudwatchダッシュボード作成して展開するのが無難かなと考え中。

Amazonlinux2023にTeratermから接続できなかった話

謎が溶けました。

弊社環境ではサーバなど構築した際、秘密鍵を作成して開発担当者やチーム内で連携するのですがとある担当者が作成したキーだけ 他のモノが使えない事象が出ていました。

キーを間違えてるのか、キーが壊れているのかなど思ってたのですが作成した担当者は使えてるようです。

ほんとに同じキー？とおもって見てみると作成者は使えて、他の者は使えないキーは同じでした。

弊社の作業PCはwindowsとMACがいます。作成者はMACです。windowsのSSHクライアントはteraterm使ってます。

作成したサーバはAmazonlinux2023です。

そうですね。

原因

Amazonlinux2023の秘密鍵の違いでした。

Amazonlinux2023では「SSH-RSAが無効化」されているためです。 そして新規で「rsa-sha2-256」「rsa-sha2-512」が有効化されています。

teratearm4.0系ではこの無効化されたものを使います。 teratearm5.0系では新規で追加されたものが使えます。

解決策

teratearm5.0に変更

teraterm4.0でも接続できるようにすることはできるがセキュリティ上古いものを有効化する必要がある。 わざわざすることも無いので新しいものに切り替え。

新しいは正義

Zabbix_AgentがAllowRoot=1でrootになれないときに

小ネタ 技術メモ

Zabbxiでログ監視をするときはrootにならないといけないときありますよね。 （ならなくてもいいときもある）

zabbix_agent.confで

AllowRoot=1

としてもAgentがroot実行されずハマりました。

結論

続きを読む

FULL VACUUMとpg_repackのロック時間比較（参考）

PostgreSQL 技術メモ

Full VACUUMしなきゃいけないことになっったので調査ついでに「VACUUM FULL」コマンドと「pg_repack」コマンドでロック時間がどれくらい違うかやってたみた。

pg_repack

github.com

感覚的な検証内容です

続きを読む