こんにちは。
キャスレーコンサルティングのSI(システム・インテグレーション)部の杉光です。

今回はAWS Athenaの機能と特徴、性能検証結果について紹介させて頂きます。

AWS Athenaとは

Athenaは昨年度のRe:Inventで発表されたAWSの新しいインタラクティブクエリサービスです。
Google Big Queryの対抗サービスとも言われています。

現時点では、Management Console(GUI)及び、JDBC接続からクエリの実行ができ、主に以下の機能があります。

自動並列実行クエリサービス

  • 利用者がコンピューティングリソースを意識する必要がなく、サービス側が必要なリソースを計算し、
    クエリが自動的に並列実行される。大容量のデータも数秒〜数分で検索・集計できる。

S3のデータに対して標準SQLで分析可能

  • ANSI SQLに準拠したPrestoがベースとなっており、関数もPrestoでサポートされているものが利用可能です。
  • Schema-On-Readとなっていて、テーブルの作成、削除、変更、
    パーティションの追加・削除のDDLをApache Hiveで作成できる。
  • 実行したクエリに対してのみ料金が発生し、1TBあたり5USDの料金が発生する。(S3の料金は別途掛かる)

その他の特徴

利用の制限

  • クエリは検索のみ。UPDATE/INSERTなどはできない。
    Hadoop特有のORCやParquetなどのファイルフォーマットを用意する場合は、
    HiveやSparkなど他のエコシステムから作成する必要があります。
  • UDFやストアド・プロシージャが使えない。
  • データベースやテーブル単位での認可が行えない。(リソースはAWSアカウントで共有されてしまいます。)
    現状はDBやテーブル単位でのIAM制御が行えないので、S3バケットに対してのアクセス制御(IAM/バケットポリシー)となります。

コストの節約

  • パーティション化による節約
    S3に格納するデータをPrefixで区切り、パーティション化することで、データの参照を限定できる。
  • カラムナデータによる節約
    ORCやParquetのデータ・フォーマットにすることにより、特定のカラムの参照に限定することができる。

Athenaの使用例

続いて、Athenaの使用方法について簡単にご説明します。

事前作業として、Athenaを使用するIAMについては事前にAthenaを実行するために必要なポリシーを付与しています。
また、データを以下のようにS3のemrtest-dataバケットに配置しました。
気象庁の過去天気データを各都市毎に格納しています。

S3-dir

AthenaのConsole画面は以下のようになっています。
4つのタブがありますが、今回はクエリの編集や実行ができる「Query Editor」をご説明をします。
画面中央部がクエリの編集&実行部になり、その下で実行結果が確認できます。

athena_1

テーブルとパーティションの作成

DB、テーブル、パーティションの作成は「Catalog Manager」からでも行えますが、
今回はHiveクエリのDDLにて作成します。
尚、DBについてはDefaltを使用します。青枠のクエリにてweather_tsvテーブルを作成しました。
athena_2

パーティションの作成

続いて、先程作成したテーブルに対してパーティションを作成します。
該当データをS3パスにて/key=valueの形式で配置したので、動的にパーティションを認識することができます。
動的にパーティションを認識するには青枠のように”MSCK REPAIR TABLE table_name“を使います。
athena_3_msck

登録されているパーティションを確認します。
例では”city”をパーティションKeyとして認識していることが実行結果からわかると思います。
athena_4_showpartition

検索クエリの実行

作成したテーブルに対してクエリ(SELECT)を実行します。
各都市毎、年毎の平均気温を降順に表示しています。(那覇が上位を占めますね・・・)
クエリの実行結果はCSVファイルでダウロードすることもできます。

athena_5_execquery

Hive/Prestoとパフォーマンスを比較

最後にAthenaのパフォーマンスを確認します。
比較対象としてApache HiveとAthenaのベースとなっているPrestoを使用します。
PrestoはFacebook社が開発した分散クエリ実行エンジンです。

HiveとPrestoはAmazon EMRを用いて性能を計りたいと思います。
EMRはHive、Presto共にアプリーケーションサポートしているので、起動が簡単です。
リソースとバージョンは以下の通りです。

各検証サービスのバージョンとリソース

Hive:2.1.1 (Tez:0.8.4)
Presto:0.157.1(Hive catalogを使用)
EMRリソース
- Master Instance : m1.mededium
- Core Instance : m4.large

対象データ

Athenaの利用例にて少し触れましたが、気象庁が提供する過去の天気データを使用しました。
(http://www.data.jma.go.jp/gmd/risk/obsdl/index.php)
項目は、日付/日中平均気温/降水量の日合計/天気概状(昼)を選んでいます。
※ダウンロードしたデータの中には品質情報や、均質番号が含まれていますが、集計対象からは無視しています。

対象フォーマットと件数

対象データのフォーマットはTSV、Parquetとし、件数はそれぞれ、オリジナルのデータ件数、
オリジナルの10倍、オリジナルの100倍の件数を用意しました。
S3への配置方法は利用例と同様に各都市毎に約60年分のデータを置いています。

検証クエリ

まず、TSV、Parquetのデータに対して以下のようにテーブルを定義します。
HiveのDDLになりますが、PrestoとAthenaともに同じクエリを使うことができます。

TSVファイル

CREATE EXTERNAL TABLE weather_tsv(
dt STRING,
temperature FLOAT,
t_1 STRING,
t_2 STRING,
precipitation FLOAT,
p_1 STRING,
p_2 STRING,
p_3 STRING,
summary STRING,
s_1 STRING,
s_2 STRING
)
PARTITIONED BY( city STRING )
ROW FORMAT DELIMITED
FIELDS TERMINATED BY '\t'
LINES TERMINATED BY '\n'
LOCATION 's3://emr-testdata/tsv3/';

Parquetファイル

CREATE EXTERNAL TABLE weather_parq(
dt STRING,
temperature FLOAT,
t_1 STRING,
t_2 STRING,
precipitation FLOAT,
p_1 STRING,
p_2 STRING,
p_3 STRING,
summary STRING,
s_1 STRING,
s_2 STRING
)
PARTITIONED BY( city STRING )
STORED AS PARQUET
LOCATION 's3://emr-testdata/parquet3/';

検索クエリ
計測対象のクエリは以下の2種類です。

検証クエリ①

--- 年毎に天気概状の中に"雪"が含まれている日を集計し、降順にソート
--- select tsv (ANSI)
select city,substr(dt,1,4),count(*) as cnt from weather_tsv where summary like '%雪%' group by city,substr(dt,1,4) order by cnt desc;
--- select parq (ANSI)
select city,substr(dt,1,4),count(*) as cnt from weather_parq where summary like '%雪%' group by city,substr(dt,1,4) order by cnt desc;

検証クエリ②

--- 年毎に平均気温を降順にソート
--- select tsv
select city,substr(dt,1,4),avg(temperature) as tmp from weather_tsv group by city,substr(dt,1,4) order by tmp desc limit 20;
--- select parq
select city,substr(dt,1,4),avg(temperature) as tmp from weather_parq group by city,substr(dt,1,4) order by tmp desc limit 20;

検証結果

各データ(フォーマット/件数/クエリ)に対する結果は以下の通りです。
(各々3回クエリを実行し、平均値を四捨五入したものになります)
※単位は秒です。

ファイル形式 TSV Parquet
件数 origin 10倍 100倍 origin 10倍 100倍
クエリ
Hive 30 35 44 45 58 83 23 19 43 45 59 84
Presto 7 3 11 7 34 43 7 3 11 7 34 44
Athena 1 2 3 3 4 3 2 1 5 3 3 3

今回の検証はEMRクラスタのリソースを小さめに設定しました。
HiveとPrestoは件数が増えるにつれて、処理時間が増していますが、Athenaは殆ど変わりないことが確認できました。
Prestoもインタラクティブクエリと言われているだけあり、データ容量とクラスタリソースの関係によっては、
Athenaに引けを取りませんでした。

さいごに

以上の結果からAthenaがリソースを意識することなくQueryを実行し、結果を得られることがわかりました。
今まではEMRでETLを行い、Redshiftで分析・集計を行うプロセスが多かったかと思いますが、
ETLを行うケースが減り、EMRのパフォーマンスに苦しんでいたエンジニアを助け、
分析官もより柔軟に素早くデータに触れる機会が増えることと思います。
現時点ではManagement ConsoleとJDBCからの利用に限られますが、
今後利用リージョンの拡充と他サービスとの連携が可能になり、利用用途も増えてくると思うので楽しみに待ちたいと思います。

参考文献

https://aws.amazon.com/jp/blogs/news/analyzing-data-in-s3-using-amazon-athena/
http://docs.aws.amazon.com/athena/latest/ug/what-is.html


皆さま、こんにちは。 キャスレーコンサルティングのSI(システム・インテグレーション)部所属の青木(和)と申します。
今回、「ブルーグリーンデプロイメント」(Blue Green Deployment)というデプロイ手法を紹介させていただきます。

開発工程に占めるリリース作業の負荷は、思いの外大きいものです。
リリース準備のために手順を整備したり、事前にリハーサルを行ったり。
また、本番環境のサーバーを停止させる必要が有るなどの制約がある場合、休日や深夜にリリースする必要があります。
ブルーグリーンデプロイメントは、こうしたリリースの作業負荷を低減させることができるデプロイ手法です。

ブルーグリーンデプロイメントとは

コード変更を行うとテスト、ビルド、デプロイなど、リリース準備までの工程を自動化してくれる「継続的デリバリー」(Continuous Delivery)という考え方があります。
ブルーグリーンデプロイメントは継続的デリバリーから派生したデプロイの方法の事で、次のことを目標にします。

  • デプロイの自動化
  • サーバーのダウンタイムゼロ

クラシックなデプロイメントは既存のサーバーに対して新しい資源を配置したり設定を更新することで行われていました。
ブルーグリーンデプロイでは環境を2つ用意し、リクエストの向き先を切り替えることでデプロイを行います。
大まかな手順は以下の通りです。

①本番環境(以下、ブルー環境と呼ぶ)に対し、アップデート環境(以下、グリーン環境と呼ぶ)を新規作成する。
②グリーン環境をルータにアタッチする。
③ルータの向き先を切り替え、アプリケーションへのリクエストの向き先をブルー→グリーンに変更する。
④グリーンの動作が安定したら完了。問題が発生した場合、向き先をグリーン→ブルーに変更し、ロールバックする。
⑤次回のリリースではグリーンを本番、ブルーをテスト環境とし、①〜④の手順でリリースを実施する。

bg_xxx

検証概要

AWSを利用して検証を行いました。
検証環境の構成は以下の図に示す通りです。

BGDeploy-Architecture

図にあるenv1(ブルー環境)が既存環境で、ユーザがURLでアクセスするとAmazon Route53(DNSサーバーの役割をするAWSサービス)によってブルー環境にリクエストが振られるようにルーティングされています。
これからenv2(グリーン環境)を追加し、設定を変更することでグリーン環境に移行を行うというのが本検証の目的です。

ブルー、グリーン各環境の構成、管理には「AWS Elastic Beanstalk」というサービスを使用します。
各環境の内部は、「ロードバランサー > ターゲットグループ > EC2インスタンス」という若干複雑な構成になっています。
Elastic Beanstalkを使用することで内部の構成をあまり意識せず、環境単位で構成管理を行うことができます。
Elastic BeanstalkにはコンソールとCLI(Command Line Interface)2つの操作方法がありますが、
検証ではCLI(ver3.7.8)を使用しています。

Elastic Beanstalk(CLI)の導入方法、使用方法については公式ドキュメントをご参照ください。
AWS Elastic Beanstalk (CLI)公式ドキュメント

リクエストの向き先を切り替える方法はいくつか考えられますが、今回は次の2つを実践しました。

  • 検証① ⇒ 2つの環境に割り振られたドメインを入れ替える方法(CNAME_SWAPによるデプロイ)
  • 検証② ⇒ DNS(Route53)のルーティング設定を変更する方法(DNSカットオーバーによるデプロイ)

検証環境作成

検証を行うのに使用した環境構築方法を以下に示します。
手順①~④はElastic Beanstalkで、手順⑤はAmazon Route53コンソールから操作しています。

①アプリケーション作成
以下のコマンドでアプリケーションを作成します。

$eb init

対話式の質問が途中で表示されるので、以下のように設定します。

  • アプリケーション名 = BGDeploy
  • アプリケーション種類 = PHP

②ブルー環境作成
①で作成したアプリケーションに環境を作成します。この環境が今動いている既存の環境と考えてください。
今回の検証では、トップページが1枚のシンプルな構成となっています。

$eb create env1

ブルー環境には以下のhtmlをデプロイします。

<html>
<head>
<title>ver1.0</title>
</head>
<body bgcolor="blue">
<font color="white">this is ver1.0</font>
</body>
</html>

デプロイ。

$eb use env1
$eb deploy

③グリーン環境作成
①で作成したアプリケーションにもう一つ環境を追加します。この環境が移行後の環境であると考えてください。

$eb create env2

グリーン環境には以下のhtmlをデプロイします。

<html>
<head>
<title>ver1.1</title>
</head>
<body bgcolor="green">
<font color="white">this is ver1.1</font>
</body>
</html>

デプロイ。

$eb use env2
$eb deploy

④確認
手順②③で作成した環境にwebブラウザからアクセスすると以下のようになります。

  • ブルー環境
$eb use env1
$eb open

bgdeploy_blue

  • グリーン環境
$eb use env2
$eb open

bgdeploy_green

⑤Route53にアプリケーションを関連づけ
手順①〜③で作成したアプリケーションを「AWS Route53」に関連づけることでDNSによるルーティングを可能とします。
Route53とはAWSのサービスの一つで、DNSサーバーの役割をします。
事前に取得した以下のドメインが、②で作成したブルー環境のエイリアスとなるように関連付けをします。
ユーザーはこのURLを叩いてアプリケーションにアクセスすると考えてください。

  • ドメイン名 : aokixyz.top

bgdeploy_route53

webブラウザからアクセスすると、ドメインがブルー環境に紐付いていることが確認できます。
bgdeploy_domain1

検証①CNAME_SWAPによるブルーグリーンデプロイメント

では、ブルー環境からグリーン環境へと移行を行います。
現在、アプリケーションへのリクエストは以下のように処理されます。

①ユーザがURLを叩く。
②Route53が名前解決を行い、ブルー環境にリクエストを振る。
③ロードバランサーがポリシーに則り、アプリケーションサーバー(EC2)へリクエストを振り、処理が行われる。

検証環境構築の中でブルー、グリーン各環境(正確には各環境のロードバランサー)に自動的にドメインが振られています。
2つのドメイン(CNAME)を交換することで、DNSで名前解決するサーバーをグリーン環境に変更し、向き先を変更します。
Elastic Beanstalkはドメイン交換の機能を持っており、以下のコマンドで簡単に行うことが可能です。

$eb use env2
$eb swap env1

以下のコマンドを実行すると、ドメインが入れ替わっていることを確認できます。
(CNAMEの項目がドメインに該当します。env1で使用していたドメインがenv2に割り振られています。)

$eb status
Environment details for: env2
  Application name: BGDeploy
  Region: ap-northeast-1
  Deployed Version: app-170104_132005
  Environment ID: e-xpjfywsf6r
  Platform: 64bit Amazon Linux 2016.09 v2.3.0 running PHP 5.4
  Tier: WebServer-Standard
  CNAME: env1.3kjeufmpnp.ap-northeast-1.elasticbeanstalk.com
  Updated: 2017-01-04 04:29:02.981000+00:00
  Status: Ready
  Health: Green

これで移行完了です。
サーバーを停止させることなく移行するという目標が達成されました。
アプリケーションのURLを叩くと新環境に移行できていることが確認できます。

bgdeploy_cswap_newapp

移行後の環境で問題が発生した場合、以下のコマンドで元のブルー環境に向き先を変更してロールバックします。

$eb use env1
$eb swap env2

ブラウザからURLを叩くと元の環境に戻っていることが確認できます。
bgdeploy_domain1

検証②DNSカットオーバーによるブルーグリーンデプロイメント

検証①ではドメイン交換することで移行を行いましたが、DNSの設定を変更することでも同じことが可能です。
Route53では「トラフィックポリシー」というものを作成することができ、これによってルーティングの向き先や重みづけなどの制御をすることができます。

今回作成するトラフィックポリシーは「加重ルーティングポリシー」と呼ばれるポリシーです。
1つのDNS名(aokixyz.top)に対して複数のリソースを関連づけ、指定した比率でルーティングすることが可能です。
例えば「ブルー100, グリーン0」であればアプリケーションへのリクエストは全てブルーにルーティングされます。
「ブルー1, グリーン1」であればブルーとグリーンに均一に分散されることとなります。

下の表のように優先度を設定し、移行前はブルー環境に、移行後はグリーン環境に向くようにします。

環境 優先度(移行前) 優先度(移行後)
ブルー 100 0
グリーン 0 100

以下の手順でトラフィックポリシーを作成します。

①Route53マネージメントコンソールから「Create policy records」を押下。
bgdeploy_route53_2

②ポリシーに名前をつけ、「Next」を押下。
bgdeploy_route53_3

③endpointに「Elastic Beanstalk environment」を選択し、ブルー環境とグリーン環境を指定する。
ルールに「Weighted Rule」を選択し、ブルー環境 = 「100」, グリーン環境 = 「0」の優先度を指定する。
その後、「Create Traffic Policy」を押下。
bgdeploy_x1

④トラフィックポリシーを作成した後、ポリシーレコードを作成する。
bgdeploy_route53_6

⑤StatusがAppliedになれば、ポリシーの作成は完了です。
bgdeploy_route53_7

ブラウザからURLを叩くとブルー環境にルーティングされていることを確認できます。
bgdeploy_route53_8

続いてトラフィックポリシーを編集して、優先度を変更します。(移行後の状態となります。)

トラフィックポリシーを編集して新しいバージョンとして保存。
bgdeploy_x2

ポリシーレコードのバージョンを新しいものに変更。
bgdeploy_x3

ブラウザからURLを叩くとグリーン環境に切り替わっていることを確認できます。
bgdeploy_route53_13

移行後の環境で問題が発生した場合、移行前のトラフィックポリシーにバージョンを戻すことでロールバックすることができます。

まとめ

長くなりましたが、いかがでしたでしょうか。

リリース時に新しい環境を作成して古い環境は使い捨てていくというのは、クラウド時代らしいデプロイ方法だと思います。
この発想は「Immutable Infrastracture」(一度サーバーを構成したら変更しないという考え方)とリンクしています。

リリースがより効率的に行われたらいいな、と思います。
ここまでお読みいただき、ありがとうございました。

参考

今回の記事の執筆にあたり、以下のサイトを参考にさせていただきました。
Martin Fowler氏のblog


こんにちは。
キャスレーコンサルティングのSD(システム・デザイン)部:野田です。

弊社はAWS(Amazon Web Services)などのクラウド環境を積極的に取り入れており、システム構築をしております。
インフラ部分はクラウドベンダーが何もかも担当してくれるため、開発土台の構築は本当に楽になったと思います。
また、パフォーマンス監視についてもクラウドベンダーにお任せしてしまうことで、運用の負担を減らすことも可能となりました。

しかし、すべてをベンダーに丸投げしても、思った通りの監視が出来ないことが多々あります。
私は最近のプロジェクトにおいて、AWS環境をNewRelicというサービスでパフォーマンス監視する開発に携わりました。
そこで、クラウド特有の監視方式にとらわれない、NewRelicでのパフォーマンス監視についてご紹介したいと思います。

そもそもNewRelicって?


New Relic は、ソフトウェア・アナリティクスを業とする米国企業。カリフォルニア州サンフランシスコが拠点。現在の CEO、ルー・サーンが 2008 年に創業した。New Relic のサービスは、ウェブアプリケーションやモバイルアプリケーションのリアルタイム監視であり、クラウド、オンプレミス、あるいはそのハイブリッド環境で稼働させることができる。提供形態は SaaS(Software as a Service)モデルである。ちなみに「New Relic」という名前は、創業者ルー・サーン(Lew Cirne)のアナグラムである。
引用-「New Relic
『フリー百科事典 ウィキペディア日本語版』より。
“最終更新 2016年2月6日 (土) 14:59″ UTC


上記のように、ウェブアプリケーション・モバイルアプリケーションのリアルタイム監視に加え、サーバ監視・ブラウザ監視までリアルタイムで確認することができるサービスです。
NewRelicを使用することの利点としては、大きく2つあります。

・監視サーバを立てる必要がない。
・収集したパフォーマンスデータを自動的にグラフ化してくれる。

それぞれについて解説していきましょう。

監視サーバを立てる必要がない

まず、パフォーマンス監視をするには必ず「監視サーバ」というものを構築する必要があると思います。
システム内でマネージャ機能を持った「監視サーバ」が、エージェントを監視する・・・。
監視の形としてはこのような構図が多いのではないでしょうか。

NewRelicでは、NewRelic側でエージェントを一元管理をしてくれるので、「監視サーバ」という存在は必要ありません。
また、監視画面はインターネット上で確認できるので、「リモート操作が出来ないから、サーバルームに入って確認しなきゃ・・・」なんて手間もありません。
監視専用のサーバを購入する必要がなくなり、購入費用の削減やサーバ台数をスリムにすることができます。

収集したデータを自動的にグラフ化してくれる

こちらも、マネージャ機能を持った「監視サーバ」でパフォーマンス状況をグラフ化してくれる機能があると思いますが、
NewRelicでは自動的にグラフ化してくれるので、インターネット上からパフォーマンス状況をグラフィカルに
確認することができます。

データ保持期間はプランによりますが、短期間・中期間・長期間でパフォーマンスの推移を確認することができます。
また、通知機能も備わっているので、閾値を設定してパフォーマンス異常に即時検知することも可能です。

いかがでしょうか。
市販の監視ソフトにも勝るとも劣らない機能が、NewRelicには備わっています。

インストールしてみよう

さて、それではNewRelicの導入方法についてご紹介していきます。
今回は以下のAWS環境に導入してみました。
・Amazon Linux AMI 2016.03.d

1.NewRelicアカウントの作成
まずはNewRelicのアカウントを作成します。

AWS環境利用者には、AWS専用の登録サイトがあるので以下のリンク先からアクセスしてください。
http://newrelic.com/aws

アカウント作成には、「Sign Up」をクリックします。

40

登録には以下の情報が必要です。
・名前
・メールアドレス
・NewRelicパスワード(任意の文字列)
・電話番号(国指定を”日本”にすること)
・国
・会社名
・従業員数
・サーバ台数

41

上記を記入し「私はロボットではありません」と、「Terms of Service」にチェックを入れ、「Sign Up for New Relic」をクリックしてください。

42

少し経つと、登録時に入力したメールアドレス宛に確認のメールが来るので、リンク先をクリックして登録が完了します。

2.NewRelicへログイン
作成したアカウントでNewRelicへログインします。
「Log In」をクリックします。

44

先ほど作成したアカウントのメールアドレス・パスワードを入力して、「Sign in」をクリックします。

45

NewRelicにログインすると、NewRelic APMの画面が開きます。

21

ここではPHPやRubyなどのソフトウェアの監視をするためのエージェントがインストールできます。
※なお今回は使用しません。

3.サーバ監視用のエージェントインストール
サーバ監視用のエージェントをインストールするので、左上から「SERVERS」を選択します。

46

サーバ監視用のNewRelicエージェントをインストールするための画面が開きます。
今回の環境は、「Amazon Linux AMI 2016.03.d」なので、「Red Hat or CentOS」をクリックします。

47

そうすると、画面下部に「Red Hat or CentOS」のインストール手順が表示されます。
手順についてはコマンドベースで記載していきます。

1.rootにスイッチします。
$ sudo su -

2.NewRelicのパッケージをインストールします。
なお、NewRelic上で表示されたコマンドでは、32bit版がインストールされます。
64bit版のパッケージをインストールする場合は、下記に記載しているコマンドを実行してください。
[32bit]
# rpm -Uvh https://download.newrelic.com/pub/newrelic/el5/i386/newrelic-repo-5-3.noarch.rpm
[64bit]
# rpm -Uvh https://yum.newrelic.com/pub/newrelic/el5/x86_64/newrelic-repo-5-3.noarch.rpm

3.サーバモニターパッケージをインストールします。
# yum install newrelic-sysmond

4.ライセンスキーの設定を行います。
アカウント毎に割り振られる番号になるので、画面上に表示されたコマンドを実行してください。
# nrsysmond-config --set license_key=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

5.サーバモニターのデーモンを起動します。
# /etc/init.d/newrelic-sysmond start

以上でインストール作業は終了です。
ここまで5分くらいでできてしまうほど簡単ですね。

監視画面を見てみよう

それでは実際に監視画面を見てみましょう
左上の「SERVERS」をクリックして再読み込みすれば、エージェントをしたサーバが一覧として表示されるはずです。

26

サーバ名をクリックすると、そのサーバの詳細なパフォーマンス状況がグラフィカルな画面として表示されます。

27

NewRelicでは、サーバの以下の項目を監視することができます。

・CPU使用率 (Overview、Processesから確認可能)
・メモリ使用率 (Overview、Processesから確認可能)
・プロセス毎のCPU、メモリ使用率 (Processesから確認可能)
・ディスクI/O、使用率 (Disksから確認可能)
・ネットワークI/O (Networkから確認可能)

左側ペインから各項目ごとに画面が用意されており、それぞれのデータが詳細に表示されます。
初めのほうにも書きましたが、短期間・中期間・長期間のパフォーマンス状況の推移をNewRelic上で確認することが出来てしまうんです。
なお、閾値設定や異常時のメール通知などの機能については、別の機会で語れたらと思います。

最後に

いかがでしたでしょうか。
今回は簡単にサーバの監視を紹介させていただきましたが、NewRelicではまだまだ出来ることがたくさんあります。
・アプリケーションレベルの監視(PHP、Rubyなど)
・Mobileの監視
・AWS環境のRDS,ELBなどのコンポーネントの監視
・MySQLなどデータベースエンジンの監視(要プラグイン) など

触れられなかった、便利な機能がたくさんあり、可能性は無限に広がっています。
私もNewRelicの奥深さを感じているので、新しい機能を覚えたら紹介させて頂きたいと思います。

最後までお読みいただき、ありがとうございました。


こんにちは。SI部の杉光です。

今回はAmazon Web Serviceの一つであるAmazon Elastic MapReduce(以下EMRと省略)を利用して
簡単に大規模データの分散処理を行う方法とEMRでサポートされているHadoopエコシステムの利用例をご紹介したいと思います。

Amazon EMRとは

EMRはAWSが提供するHadoopクラスターのサービスです。

クラウドサービスなので、わずか数分で仮想サーバーのクラスターを立ち上げ可能にし、
計算能力の需要に合わせクラスターを構成するサーバー数を調整することが可能です。
時間単位の課金なので、大量のデータを直ぐに短期間で処理したい場合も高いコストパフォーマンスで対応できます。

また、他AWSサービスとの連携が可能で、S3、RDSやDynamoDBに保存されたデータにクラスターからアクセスが可能です。
とりわけ、S3はHDFSと分けて意識することなくデータを保存することができます。 (続きを読む…)


こんにちは。

田中(邦)です。

今回はAmazon Simple Queue Service(Amazon SQS)Amazon Simple Notification Service(SNS)を使ってAndroid端末にプッシュ通知を送信する仕組みを実装していきます。

(続きを読む…)


こんにちは。利根川です。

社内のプロジェクトで Redmine 導入の要望があります。
Redmine には Bitnami等のオールインワンパッケージが存在しますが、
今回はIPA(独立行政法人情報処理推進機構)が提供する
定量的プロジェクト管理ツールの導入を検討しています。

今回は、Amazon EC2 上のサーバーに定量的プロジェクト管理ツールを導入し、
プロジェクトを立ち上げるまでの手順をご紹介いたします。 (続きを読む…)


こんにちは田中(巧)です。

社内活動の中で多少要望も頂いたので、
今回はAWSでのWebConsoleによるEC2インスタンス立ち上げの手順を少し詳細に書こうと思います。 (続きを読む…)


こんにちは。田中(邦)です。

先日、キャスレー主催のハッカソンを行いました。

土曜日開催にも関わらず多くの方々にご参加いただき大変な盛り上がりを見せたハッカソンなのですが、今回はその準備と反省点について少し書いていきたいと思います。 (続きを読む…)



  • Profile
    キャスレーコンサルティングの技術ブログです。
    当社エンジニアが技術面でのTips、技術系イベント等についてご紹介いたします。
  • CSV社長ブログ
  • チーム・キャスレーブログ