mamori017.log

雰囲気でクソコードを書いてバグを作っています

nuroモバイルの0SIMをHuawai HW-02Gで使うことにした

f:id:mamori017:20171117014051j:plain

nuroモバイルの0SIMを休眠状態にしていたのですが、 もったいないので中古のHuawei HW-02Gを購入して運用することにしました。

nuroモバイルの動作確認済み端末の一覧に記載がなかったので使えるか若干不安ではあったのですが、 APN設定も問題なく済ませられたのでさっそく速度計測してみました。

計測は金曜19時、場所は広島市の本通り交差点です。 週末の通勤時間帯、人も多かったこともあり速度は出ませんでした。

f:id:mamori017:20171118160100p:plain

土曜の午前1時、場所は同じく本通り交差点です。 今度は人がいないだけあって予想より良い結果でした。

f:id:mamori017:20171118160957p:plain

速度面は0SIMなので流石に文句は言えないですが、ルーターに関してはLTEを4バンド掴める端末としては安く手に入れられたので良かったです。

Amazon Athenaを使ってみる

Amazon S3に保管したログなどをSQLで解析できるというAmazon Athenaを触ってみました。 コマンドラインからだと結果が見づらいようなのでマネジメントコンソールから見てみます。

今回は事前に手持ちのIISログをS3バケットに放り込んでいます。 また、IISログについては値の区切りが半角スペースなので、Athenaで使いやすいようにタブ区切りに変更してあります。

データベースの設定

f:id:mamori017:20171003160737p:plain Athenaで使用するデータベースの設定を行います。データベース名とテーブル名、Athenaで参照するS3のバケットを指定します。Athenaで対象バケットを指定する際、S3のパスは「S3://{バケット名}/{フォルダ名}」になりますが、 パスの最後に必ず「/」を記述していないとエラーになるようです。

ファイル形式の指定

f:id:mamori017:20171003160740p:plain 対象となるIISログはタブ区切りにしておいたのでTSV形式を選択しました。

カラムの設定

f:id:mamori017:20171003160745p:plain カラムのデータ型を指定します。 IISログで出力した項目別に列を設定しました。 キャプチャ上はString型になっていますが、 間違って2項目目にtimestamp型を指定してしまったため、 のちのクエリの実行結果でデータが出力されませんでした。

パーティション

f:id:mamori017:20171003160746p:plain パーティションの設定はスキップしました。 データ量が膨大になるとこの設定も必要になりそうです。

テーブル作成

f:id:mamori017:20171003160748p:plain テーブル作成クエリが表示されているのでRun Queryで実行します。 クエリの実行結果が正常であれば、 Athenaに指定したS3バケットのデータを対象としたテーブルが作成されます。 キャプチャはiisデータベースにw3svc1テーブルが作成された状態になります。

クエリの実行

f:id:mamori017:20171003160750p:plain 試しにクエリを実行してみました。 ログ行は区切りごとに列として表現されていますが、不要なIISログヘッダまで対象データとして判定されているので、 対象ファイルをバケットに登録する以前に、不要な行はそもそもログとして出力しない方が良さそうです。 また、キャプチャの5レコード目以降がログの有効行になるのですが、time項目をtimestamp型にしてしまっているので型が合わず空欄で出力されています。

実行結果ログ

f:id:mamori017:20171003160752p:plain

Athenaにデータベースを作成した時点で、S3にAthena実行結果用バケットが自動的に作成され、クエリの実行結果がCSV形式で保管されるようになります。 誤ってこのバケットを削除してしまった場合、コンソール上ではエラーが出力され続けるので、 削除してしまった場合は指定された名称でバケットを作成し直すか、保存先のバケットをコンソール右上のSettingsから指定する必要があります。

使ってみた感想・メモ
  • 定期的に実行する必要のあるクエリはビューの感覚でSaved Queryで保存しておけるので便利。
  • 列数が合わない行も左詰めで対象行となる。(IISログで言うとヘッダ行)
  • 条件にヒットした行は出力対象となるが、列に指定したデータの型が合わない結果は空欄で表現される。
  • 実行結果がS3の指定バケットに貯まり続ける。
  • DDLリクエストは課金対象とならない。
  • 列指定するとデータスキャン量が減るので1リクエストあたりの課金が抑えられる。
  • 生のファイルサイズが大きい場合はデータを圧縮することで課金が抑えられる場合がある。
  • 500KB弱のログファイルに対してクエリを実行し続けたけど、請求エクスプローラ上ではほぼ0円。
  • 本来の使い方ではない気はするけど、今後はDB立てるまでもないデータをSQLで操作したいときに使っていきたい。

Amazon Web Services実践入門 (WEB+DB PRESS plus)

Amazon Web Services実践入門 (WEB+DB PRESS plus)

AWSエキスパート養成読本[Amazon Web Servicesに最適化されたアーキテクチャを手に入れる! ] (Software Design plus)

AWSエキスパート養成読本[Amazon Web Servicesに最適化されたアーキテクチャを手に入れる! ] (Software Design plus)

AWS Lambdaでタイムアウトを発生させてみる

AWS Lambdaで関数実行中にタイムアウトするとどうなるのか見たことが無かったのでためしにやってみました。

Lambdaで空の関数を作成し、ランタイムにPython3.6を選択したときに作成されるコードをsleepで10秒止めてみます。

import time

def lambda_handler(event, context):
    time.sleep(10)
    return 'Hello from Lambda'

テスト実行するだけなのでLambdaの設定はデフォルトのままにしました。 タイムアウトの時間はデフォルトで3秒なので、関数がsleepで止まっている間にLambdaが処理を終了させるはずです。

テストしてみたところ実行結果にタイムアウトのエラーメッセージが出力されました。

{
  "errorMessage": "2017-09-05T02:03:28.155Z xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx Task timed out after 3.00 seconds"
}

f:id:mamori017:20170905105252p:plain

ついでなので、CloudWatchのアラームでLambdaの実行エラー時にSNSが送信されるように設定*1しました。 f:id:mamori017:20170905115800p:plain

アラーム作成後にLambda関数をテスト実行すると、アラームの状態がデータ不足からアラームに変わります。

f:id:mamori017:20170905124002p:plain

同時に、アクションに設定していたSNSトピックの送信先メールアドレスにメッセージが送信されます。

f:id:mamori017:20170905124310p:plain

Amazon Web Services実践入門 (WEB+DB PRESS plus)

Amazon Web Services実践入門 (WEB+DB PRESS plus)

AWSエキスパート養成読本[Amazon Web Servicesに最適化されたアーキテクチャを手に入れる! ] (Software Design plus)

AWSエキスパート養成読本[Amazon Web Servicesに最適化されたアーキテクチャを手に入れる! ] (Software Design plus)

*1:本来はLambdaのリトライを考慮したうえでCloudWatchのアラートの閾値と間隔を設定すべき。