ruby3.0で「hashをキーワード引数に自動変換する機能」の削除がリスケされた流れを自分なりに理解する記事

なにこれ

ruby3.0で「hashをキーワード引数に自動変換する機能」を削除する予定だったけど、延期もしくは中止する

と、Matzがrailsのフォーラムでコメントしていたので、その経緯とかを把握するために記事にしました

discuss.rubyonrails.org

そもそも、hashをキーワード引数に自動変換する機能って?

def a(hoge:)
  p hoge
end

a(hoge: 'a')
a({hoge: 'b'})

こんな感じに、メソッドがキーワード引数の場合、hashを引数に渡しても良い感じに解釈してくれる機能

なんで自動変換機能が削除されるの?

この機能のために、バグが発生したり、機能の追加が面倒という欠点があったので、2017年頃には、ruby 3.0.0 からは削除されるという話が出ていた

また、その前準備の期間として、ruby 2.7では、非推奨の機能とされ、Warningが出るように変更された

上のコードをruby2.7.1で実行すると警告が出る

01.rb:6: warning: Using the last argument as keyword parameters is deprecated; maybe ** should be added to the call
01.rb:1: warning: The called method `a' is defined here

techracho.bpsinc.jp

なんで自動変換機能が削除が延期されたの?

Railsフォーラムで、上記の警告が大量に出過ぎて鬱陶しい & 対応がすごい大変という話が上がった(らしい)

それに対して、Matzが以下のようにフォーラムにコメントした

  • 多すぎるWarningがノイズになっているのを認識している。2.7.2ではWarningを消すか減らす
  • 移行コストを低く見積もりすぎていた
  • 上記のために、ruby3.0でキーワード引数をどうするか(延期/中止)検討する

👇リスケに関しての記事

techracho.bpsinc.jp

今後どうするの?

Ruby側は、以下のissueで議論するらしい

bugs.ruby-lang.org

感想

  • Rails使っていて、rubyのアップデート考えている人は、Ruby側の結論と、それに対してのRails側の反応を見てから、どうするか決めたほうが良いんじゃないですかね
  • ruby2.7系については、APIレベルでの非互換性がある変更は無いはずなので、特に慌てることは無いのでは

AWS WAF Regionalの情報を取りたい場合、使うのは Aws::WAFRegional::Client だよ! というお話

これで2H程度ハマってしまった...

言いたいこと

  • AWS WAFには、グローバル(CDN用)と、Region単位の Regional がある
  • ruby SDKでWAFの情報を取りたい場合、グローバルとRegionalでは使用するclientが異なる
    • グローバルならば、 Aws::WAF::Client
    • Regional ならば、 Aws::WAF::WAFRegional

Aws::WAF::Client もドキュメントでは、引数に region を指定できるので、ここを指定すれば、Regional の情報が取れると勘違いしていた...

Amazon EventBridge おぼえがき

Amazon EventBridge って何?

Amazon EventBridge は、独自のアプリケーション、統合 Software-as-a-Service (SaaS) アプリケーション、および AWS のサービスからのデータを使用して、アプリケーションを簡単に接続することを可能にするサーバーレスイベントバス

aws.amazon.com

つまり?

SaaSとAWSのサービスをグルーコードなしで接続できるサービス

例えば、今までだったら Mackerel -> Webhook -> API Gateway -> lambda とかで実現していた処理を Mackerel -> EventBridge -> lambda とかでシンプルに実現できる

どんなSaaSと接続できるの?

ここから見れる

自分が使いそうなところだと

  • PagerDuty
  • Datadog
  • New Relic
  • Mackerel

どうやって連携するの?

例えばMackerelだと、ヘルプページに詳細が書かれてる

mackerel.io

これに沿って設定をすれば、例えばmackerelのアラート発生時に lambda を叩くみたいなのを、API Gatewayを経由せずに実行したりできる

Amazon EventBridge の特徴。イベントバス

イベントバスって?

要はこういうものらしい

f:id:kasei_san:20200327230502p:plain

  • 送信者が受信者を意識せずに、イベントを送信できるサービス
  • イベントバス管理者が、どのように誰が受信するかを制御する

AWSのアカウント毎にイベントバスが存在し、Amazon EventBridge はそこからイベントを取り出す

それって、Amazon SNSでよくない?

1つのアカウントでサービスが完了していたらSNSで良いはず

しかし、Amazon EventBridgeのイベントバスは他のアカウントにイベントを飛ばすことができる...! ので、こういった組織間でイベントを連携したい場合に使える

f:id:kasei_san:20200327231215p:plain

まとめ

  • Amazon EventBridge はイベントバスを制御することで、イベントのやり取りを簡単にするサービス
  • 送信側は最終的な受信先を意識する必要は無く、イベントバスに送るだけでよい
  • イベントバスの管理者が、受けたイベントをどうするか管理する
  • イベントバスでは、SaaS、アプリケーション(カスタムイベント)、CloudWatchEvent、他アカウントからのイベントなどを受けることができる
  • 1アカウント単体で使用する場合も、SaaSとAWSの連携にグルーコードが不要となるというメリットがある(通常のwebサービスだとこっちがメインの使い方になるはず

参考

http://d1.awsstatic.com/webinars/jp/pdf/services/20200122_BlackBelt_EventBridge.pdf

  • AWS BlackBelit の EventBridge 解説記事

SNSの代わりにEventBridgeを使用すべき5つの理由| ルミゴ

  • SNSではなくEventBridgeをつかう5つの理由を解説

AWS Fargate のコスト削減アイデアいろいろ

AWS Fargate。便利だけど、EC2と比べるとコストも高いので、コスト削減の方法をいろいろまとめてみた

  • 上から順に効果が高くて、適用コストも低いので、上から実施を検討すると良いです

Compute Savings Plans

  • EC2やFargateやlambdaの利用について、1時間いくらで、1年 or 3年分契約することで割引が発生するプラン。前払いにすると更に割引
  • 前払いならば、東京リージョンのfargeteで、 1年なら22%OFF、3年なら47%OFF
  • インスタンスタイプなどに縛りはないので、一定額 EC2やFargateやlambda を使用するならば、入ったほうが得なことが多いハズ

構成変更も不要なので、まずはここから始めると良い

参考

dev.classmethod.jp

Fargate Spot

  • 不意に中断することがある代わりに、70%OFF で Fargate が利用できるサービス
    • Compute Savings Plans との併用はできない
    • ほとんど中断することはない様子

  • Capacity provider strategy で、task の起動時のFargate Spotの割合を設定可能

つかいどころ

  • 停止しても大きな問題が無い、QAやstaging環境
    • 自分の会社では、Spot にして、さらに土日深夜早朝停止することで、かなりの低コストでQA環境を運用できた

techblog.lclco.com

構成変更のコストも低く、停止することも今の所ほぼ無いので、stage環境があるならば、まずはSpotの利用をオススメ

あとは、失敗しても再実行すれば良いバッチ処理とか、Capacity provider strategyを使って本番の一部とか

参考

blog.kasei-san.com

メモリ、CPU、task数の調整

メトリクスを取っていることが前提

  • ピークタイムでもメモリ、CPUに余剰があるならば、task数の削減を検討
  • 最低維持task数 = AZの数 でもまだ余裕があるならば、メモリ、CPUの削減を検討
    • ただし、1個のAZが落ちても、余裕があるようにしておくこと
    • 2AZならば、maxでも50%にしておく
  • ピークタイムとそれ以外でメモリ、CPUの使用量に大きな差があるのであれば、オートスケーリングを検討

半年に1回くらい状況を見て、メモリ、CPU、task数を調整するとハッピーかもしれない

リクエスト数をへらす

キャッシュが最適化されていないのであれば要検討

必要なCPUやtask数が削減されるはず

まとめ

もし、Fargate Spot化や メモリ、CPU、task数の調整がすぐできるのならば、Compute Savings Plansの適用はその後にした方が良いかも

bash にて、とあるドメインが存在するなら、環境変数にそのドメインを格納する、なければデフォルト値という処理を書いたときのメモ

コード

API_URL=https://example.com
BRANCH_API_URL=https://hoge.com
host ${BRANCH_API_URL#https://} && API_URL=${BRANCH_API_URL} || :

ポイント

  • ${BRANCH_API_URL#https://} で、環境変数 BRANCH_API_URLの先頭の https:// を取り除いている
  • host は引数のドメインが無い場合、異常終了するコマンド
  • : は何もしないコマンド
  • これにより、 以下のような処理が実現できる
    • host が正常終了すれば、 API_URL には、BRANCH_API_URL が格納される
    • host が異常終了すればなにもしない(結果として、API_URL はデフォルトの https://example.com のまま

参考

qiita.com

AWS Codebuild で dig とか host コマンドを使う方法

先に方法

buildspec に以下を追加

phases:
  install:
    commands:
      - yum -y install bind-utils

解説

  • AWS Codebuild で動作させる、Amazon Linux 2 (centOSベース) には、host や dig コマンドがインストールされていない
  • host や dig コマンド は、bind-utils でまとめてインストールされる
  • buildspec にて、ビルド前になにかインストールしたい場合は、 install phase で実行する

Fargate Spot おぼえがき

先にまとめ

  • コンテナが不定期に停止する代わりに 通常価格の70%OFF になるサービス
    • Savings Plansとの併用はできない。らしい (伝聞のためソースなし
  • 雑に始めたければ、Capacity Provider を FARGATE SPOT のみにする
    • Fargete と Fargate Spot を併用したければ、Capacity provider strategy を設定する
  • 停止の120秒前に Amazon EventBridge で通知がくる
    • ただし、2019/12月時点の東京リージョンでは、80H稼働し続けても特に死ぬことはなかったらしい

想定される使いみち

  • 中断しても困らない並列処理や分散処理
  • QA環境などのテストサーバ
  • 本番サーバのバッファ

Fargate Spotの雑なはじめかた

ECS の Capacity Provider を FARGATE SPOT のみにする

f:id:kasei_san:20200311082737p:plain

Capacity Provider って何?

ECSのクラスターの実行環境。Fargete ならば FARGATEFARGATE SPOT がある

  • FARGATE を消してしまえば、 Capacity Provider は FARGATE SPOT のみなので、全ての task が Fargate Spot で実行される
  • 余談。ECS on EC2 ならば、ECS Cluster Auto Scaling も追加可能
    • これは、コンテナの増減に応じて、EC2のスケールイン/アウトを自動にしてくれるサービス
    • これまでは、個別に管理する必要があったので大変だった

Capacity provider strategy

もし、 FARGATEFARGATE SPOT を併用したい場合、Capacity provider strategy という設定で、task実行時の Capacity Provider の配分を決めることができる

コンテナの停止を検知する方法

Amazon EventBridge を使う

Amazon EventBridge とは

AWSとSaaSを統合するために、AWSで発生するイベントを他のAWSサービスやSaaSと紐付けるサービス

Amazon EventBridge は、独自のアプリケーション、統合 Software-as-a-Service (SaaS) アプリケーション、および AWS のサービスからのデータを使用して、アプリケーションを簡単に接続することを可能にするサーバーレスイベントバスです。

aws.amazon.com

Amazon EventBridge と SNS ってどう違うの?

大規模に素早く pub/sub したい場合は SNS。いろいろなサービスと手軽に繋がりたい場合は、EventBridge という感じらしい

lumigo.io

参考

aws.amazon.com

dev.classmethod.jp

dev.classmethod.jp

blog.astj.space