Skip to content
サーバーラック

AWS の r3 より r4 + EBS の方が安くて速かった

AWS の r3 より r4 + EBS の方が安くて速かった published on AWS の r3 より r4 + EBS の方が安くて速かった へのコメントはまだありません

結論

AWS の r3 系インスタンスを使っている人は、r4 系 + ディスク追加に切り替えると、値段が安くなってパフォーマンスも上がる可能性が高い。

背景

仕事で、EMR 上で Sparkを 使っている。処理としては、1日1回のバッチ。(詳細は書けないので省略。)

日によってデータ量にばらつきがあり、persist した時に、メモリに入りきらず一部ディスクに書き込まれる時がある。ちなみに、storage level は MEMORY_AND_DISK を指定している。

インスタンスタイプは、r3 系を数十台使っている。

途中からプロジェクトに加わったので詳しい経緯は分からないけど、ディスクも使うため、インスタンスストアのある r3 を使っているものと思われる。スペックの違い等は、以下のページを参照。

インスタンスタイプ – Amazon EC2 | AWS

r4 の方が安いが、EBS のみ

以下の価格表を見ると、r3 インスタンスの後継(?)である r4 インスタンスの方が安い。

EC2 インスタンスの料金 – アマゾン ウェブ サービス (AWS)

が、r3 インスタンスには付いていたインスタンスストア(SSD)が r4 インスタンスには付いていない。

また、色々調べてた時に見た以下のブログ記事に、

東京リージョンで「r4」インスタンスが利用可能になりました | Developers.IO

以下のような記述があった。

現在、「r3」のオンデマンドで稼働中であったり、リザーブドインスタンスの契約更新を控えたEC2インスタンスについては、 利用中のストレージを確認し、EBSのみの利用でである場合には、「r3」→「r4」への変更を検討頂ければと思います。

なので、ディスクを使いたい場合は r3 を使う必要があると思いこんでいた。

ディスクは追加出来る

一旦、r3 での運用で落ち着いていたけど、やはりコスト削減はしたい。ということで、もう少し調べてたら、EMR のインスタンスには EBS ボリュームを追加することが可能。詳細は以下のページを参照。

インスタンスストアと Amazon EBS – Amazon EMR

ということで、r3 → r4 + ディスク増設に切り替えてみた。

結果・・・

  1. 時間あたりの料金削減(r3とr4の差額分削減、EBS追加分増加、トータルでは削減)
  2. バッチ処理時間削減

となった。2は予想外だったけど、以下のページにちゃんと書いてあった。

次世代のメモリ最適化EC2インスタンス(R4) | Amazon Web Services ブログ

大きなL3キャッシュと高速なメモリを搭載することで、既存のR3インスタンスより高い性能を発揮します。

ちなみに、ディスク追加の方法だが、GUI の場合は、画面から EBS を追加できるはず。(やったことないので未確認。)CLI の場合は、create-cluster の –instance-groups で EbsConfiguration を指定する。

詳細は以下のページを参照。

create-cluster — AWS CLI 1.11.136 Command Reference

まとめ・雑感

リザーブドインスタンスが残っているのでなければ、一般的には最新のインスタンスに乗り換えたほうが良い。あと、やっぱり、オフィシャルのドキュメントをしっかり読み込むのが大事。

DynamoDB + S3 + EMRでコホート分析(cohort analysis)をする(3)

DynamoDB + S3 + EMRでコホート分析(cohort analysis)をする(3) published on DynamoDB + S3 + EMRでコホート分析(cohort analysis)をする(3) へのコメントはまだありません

前回からかなり間が空いてしまったけど、今回で完結予定。

前回はHiveの話を中心に、S3に置いたファイルをHiveでどう扱うかなどについて書いた。また、第1回では全体の流れを書いたので、どんなことをやるかは詳しくはそちらを参照。

今回は、DynamoDBに書き込んでいるデータを定期的にS3にエクスポートしたり、MySQLからエクスポートしたデータに対して、EMR上のHiveからクエリーを実行して結果を取得してみる。

Continue reading DynamoDB + S3 + EMRでコホート分析(cohort analysis)をする(3)

DynamoDB + S3 + EMRでコホート分析(cohort analysis)をする(2)

DynamoDB + S3 + EMRでコホート分析(cohort analysis)をする(2) published on DynamoDB + S3 + EMRでコホート分析(cohort analysis)をする(2) への2件のコメント

ちょっと前回から間が空いてしまったけど、DynamoDB上のデータやその他のデータをS3に集めて、EMR上のHiveを使ってコホート分析をするという話の第2回。今回はHiveの話を中心に書いていく。

※Hiveを使うのは今回が実質初めてで、EMRについてもあまり経験は豊富ではないので、何かおかしい点などがあったらご指摘頂けると幸いです。

Continue reading DynamoDB + S3 + EMRでコホート分析(cohort analysis)をする(2)

DynamoDB + S3 + EMRでコホート分析(cohort analysis)をする(1)

DynamoDB + S3 + EMRでコホート分析(cohort analysis)をする(1) published on DynamoDB + S3 + EMRでコホート分析(cohort analysis)をする(1) への1件のコメント

コホート分析とは

定義に関してはWikipediaを見れば大体わかるかと。日本語のエントリーがないので、大雑把に説明すると、ユーザーをグループ(コホートと呼ばれる)に分割し、各コホート毎に指標(例えば、ユーザーごとの滞在時間)を集計して分析することをコホート分析(cohort analysis)と呼ぶ。

よくある質問として「セグメント分けとどう違うの?」っていうのがあって、セグメントは例えば性別とか年代とかのユーザーの属性によって分割するのに対して、コホートは登録日時、初回ログイン日時といった、ユーザーの行動を元にグループ分けするというのが違い、だと思う。

Continue reading DynamoDB + S3 + EMRでコホート分析(cohort analysis)をする(1)