技術めも

awsのIPv6対応状況をまとめてみる。

■ELB

dualstackから始めるドメインであれば、IPv6対応である。

Route53を使う場合は、AAAAのaliasを貼ればよく、

他DNSを使う場合は、CNAME設定になるのかな？

dualstack.XXX.ap-northeast-1.elb.amazonaws.com

■S3

こちらもdualstackのドメインであれば対応済みということである。

https://aws.amazon.com/jp/blogs/news/now-available-ipv6-support-for-amazon-s3/

■Cloud Front

こちらは執筆時点では対応発表済みであるが、

逐次対応が進んでいる状況である。

そのため、ひょっとしたら、設定したにも関わらず、

名前解決できない可能性もある。

https://aws.amazon.com/jp/blogs/news/ipv6-support-update-cloudfront-waf-and-s3-transfer-acceleration/

その他、EC2などはIPv4を前提とした設計となっているため、

対応にはしばらくかかるだろう。

ただ、外向きの部分において、awsはIPv6対応を着実に進めているため、

appleのATS問題などは回避できそうである。

その他、私が知っている限りだと、

• さくらVPS
• さくらクラウド

はIPv6対応が結構すすんでいる。

ただし、さくらクラウドは共用ネットワークではIPv6が利用できなかったので、注意が必要。（※あくまで執筆時点）

さくらは比較的早期からIPv6対応していたので、近いうちにもろもろ対応してくれるだろう。

以上

AWSのCDNであるCloudFrontを利用したので、

その特徴を記載しておく。

良い点
・L7レベルで動作
たとえば2つのオリジンを設定して、
パスパターンによって、振り分け先を変更できること。
静的コンテンツはS3に、動的コンテンツはELBに振るなどが可能。

・独自ドメインでのSSLが利用可能
S3では出来ない独自ドメインSSLが利用可能。

・AWS内のオリジンとは高速な通信
オリジンがELBの場合、ELB配下のインスタンスが巨大な画像等を返す場合、
通信が安定しているcloudfrontに返すほうが、インスタンスの負荷は下がる。

悪い点
・変更反映が遅い
15分くらいかかるのだろうか。

・キャッシュ削除が遅い
これも15分くらいかかっている感じがする。

・連続的にGETアクセスした場合にキャッシュさせたくなくてもキャッシュされる
例えば2つオリジンを設定して、片方を静的、もう片方を動的とする。
動的コンテンツ側に振られるURLに瞬間的に連続アクセスした場合、すべてのリクエストが動的コンテンツ側に来るわけではなく、
cloudfrontにキャッシュされてしまう。
後述するキャッシュのヒット条件にもよるが、
キャッシュさせないはずの動的コンテンツが、実際にはキャッシュからエンドユーザに返される可能性がある。
最も簡単・確実に回避するためには、URLに一意のクエリ文字列を付ければよい。（JSを使って、タイムスタンプ＋ランダム文字列などを付与する）

・オリジンへ渡すヘッダー情報がキャッシュキーの種となる
オリジンへ渡すヘッダーとしては諸々設定が可能だが、
動的コンテンツをオリジンとする場合、user-agentなどを通ししまうと、
それがキャッシュキーの種となり、結果としてキャッシュヒット率が下がる。
この場合は、cloudfront独自の「IS_MOBILE」的なヘッダーを付けて、オリジン側で判定として使える。
逆に言うと、cloudfrontを使う場合、オリジンで「IS_MOBILE」などの判定処理を用意しておく必要がある。

CloudFrontは設定が細かく、結構難しい。

ただ、統計情報も充実しており、

なんといっても高負荷に強く、エッジロケーションも広いので、

上手く使えば非常に強力な製品だと感じた。

気を付けるべきは、動的コンテンツを背後に置く場合だろう。

キャッシュ条件、キャッシュ生存期間など、動的コンテンツ作成者側が意識しておくことで、

より有用なものとすることが出来ると思う。

最近は、CDNが多用されているので、

各CDNの特徴をよく確認し、十分に検証したうえで、

導入を検討するとよいと思う。

他のCDNについても、機会があれば書いてみようと思います。

以上

GCPとAWSで、拠点（リージョン）間の通信速度を簡単に図ってみた。

正確ではないし、3回程度しか実施していないので、その点は考慮ください。

■ComputerEngineのインスタンス（ASIA）から（AMERICA東部）への２３０MBのSCP

24秒

■EC2のインスタンス（TOKYO）から（AMERICA東部）への２３０MBのSCP

23秒

ほとんど同じ。

GCPはネットワークの強さをうたっているが、AWSと変わらないケースもある。

GCPの場合、ローカルネットワーク上で、異なるリージョンのインスタンスをまとめられるので、

データベースなどを複数リージョンで準同期レプリケーションできるとよいと思っていたが、

その目論見は成立しそうにないことがわかった。

ただし、GCPはグローバルロードバランサーとか、CloudStorageがめちゃくちゃ優秀だから、

実際にサービスとしてユーザの体感速度的なものは、広域範囲で考えればAWSより優秀なのではないか。

ローカル環境にS3環境を構築できる「S3 ninja」なるものを入れてみたので、

備忘録を残しておく。

• ダウンロード

http://s3ninja.net/

上記からzipファイルを落として解凍すればよい。

• 初期設定

解凍した直下に、「instance.conf.sdsignore」というファイルがあるので、

これを「instance.conf」とする。

また、dataフォルダがあるので、

その下に「s3」フォルダを作成する。

• 起動

以下を実行すれば、「http://localhost:9444」でアクセス可能となる。

$ ./sirius.sh start

phpとjavaからアップしたが、本物とは違ったので、

コードを記載しておく。

なお、前提として、「http://localhost:9444」にアクセスして、

事前に「test」というバケットを作り、「public」にしておくものとする。

phpコード

<?php
require_once("aws.phar");
$bucketName = "s3";
$accessKey = "AKIAIOSFODNN7EXAMPLE";
$secretKey = "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY";
$keyName = "test/php/000.text";

$s3 = new Aws\S3\S3Client(array(
    'credentials' => array(
        'key'    => $accessKey,
        'secret' => $secretKey,
    ),
    'version' => "2006-03-01",
    'region' => "us-east-1",
    'endpoint' => "http://localhost:9444/",
));

$r = $s3->putObject(array(
   'Bucket' => $bucketName,
   'Key' => $keyName,
   'Body' => fopen("test.txt", "r"),
   'ACL' => 'public-read',
   'CacheControl' => 'no-store, no-cache',
));
var_dump($r);

javaコード

package sample.ninja_test;

import java.io.File;

import com.amazonaws.auth.BasicAWSCredentials;
import com.amazonaws.services.s3.AmazonS3Client;
import com.amazonaws.services.s3.S3ClientOptions;
import com.amazonaws.services.s3.model.CannedAccessControlList;
import com.amazonaws.services.s3.model.PutObjectRequest;

public class App
{
  private static final String keyName = "java/000.text";
  private static final String bucketName = "test";
  private static final String accessKey = "AKIAIOSFODNN7EXAMPLE";
  private static final String secretKey = "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY";

  public static void main(String[] args) {
    AmazonS3Client client = new AmazonS3Client(new BasicAWSCredentials(accessKey, secretKey));
    client.setS3ClientOptions(new S3ClientOptions().withPathStyleAccess(true));
    client.setEndpoint("http://localhost:9444/s3");

    PutObjectRequest putObj = new PutObjectRequest(bucketName, keyName, new File("test.txt"));
    putObj.setCannedAcl(CannedAccessControlList.PublicRead);
    client.putObject(putObj);

    String url = client.getResourceUrl(bucketName, keyName);
    System.out.println(url);
  }
}

期待した設定としては、javaのコードが正しい。
phpのコードはちょっと設定がおかしい。

とはいえ、この辺は、プログラムの設定等で吸収できるので、
簡易的なテストツールとしてはいいかもしれません。

AWSのRDSにmariadbが追加されましたね。

xtradbのサポートはあるようだけど、

mariadbのクラスター関連のエンジンはサポートしていない感じがする。

AWSの場合、Auroraがあるから、mariadb流行らないかも。。

クラスター関連をサポートしてくれないかな。。

redshiftからクエリーを引くのが遅い。。

そして、アナウンスなしにマイナーバージョンアップが多い。。。

データの格納庫としては、

とても優れているけど、

データの引っ張る際は、

直接クエリーで引いてもよくないな。。

RDB側へサマリーしておいて、

それを引いたほうがいいかも。。

今後に期待。

awsのELBを使うと、

websocketの場合、

handshakeから60秒がタイムアウトだと思っていた。

しかし、最後の通信（おそらく受信も含む）から60秒がタイムアウトであった。

60秒無通信っていうのは受信も考えるとあまりないかなと。。

また、ELBのタイムアウトも延長できるみたいだから、

websocketを通す場合は、タイムアウトを延長するのも

一つの手段にはなるかなと。

前回、awsにtd-agentを入れて、

s3→redshiftとの連携を図ったけど、

さらにうまくやる方法を記載しておく。

●カラムを超えた場合のデータについて

TRUNCATECOLUMNS

オプションを付けておくことで回避できる

●redshiftに取り込まれた日時を登録する方法

テーブル側にカラムを追加して、jsonpathとのカラムミスマッチを防ぐ

具体的には、

CREATE TABLE test_access_logs (
    date            datetime sortkey,
    ip              varchar(64),
    header          varchar(256),
    code            varchar(16),
    size            varchar(16),
    aaa             varchar(64),
    bbb             varchar(128),
    ccc             varchar(128),
    second          varchar(16),
    insert_date     datetime  not null default convert_timezone('JST', getdate())
);

上記みたいに、insert_dateを追加する。

ただし、このまま取り込むと、

{
    "jsonpaths": [
        "$['date']",
        "$['ip']",
        "$['header']",
        "$['code']",
        "$['size']",
        "$['aaa']",
        "$['bbb']",
        "$['ccc']",
        "$['second']"
    ]
}

カラムのミスマッチがおきてしまう。

これを回避するために、

# COPY test_access_logs
  (date, ip, header, code, size, aaa, bbb, ccc, second)
  FROM 's3://MY-BUCKET/logs/httpd/201501/26/'
  credentials 'aws_access_key_id=XXX;aws_secret_access_key=YYY'
  JSON AS 's3://MY-BUCKET/logs/httpd/test_access_log_jsonpath.json'
  GZIP
  COMPUPDATE ON
  RUNCATECOLUMNS;

上記のように、カラム指定で取り込むと、

insert_dateはnullになり、defaultが適用される。

なぜこのような方法をとるかというと、

もし再取り込みが発生した場合に、

以前のデータを消さないで取り込むと、

重複で取り込まれてしまう。

重複を回避するには、

以前取り込んだデータを削除しなければならない。

insert_dateを登録しておけば、

以前登録したデータを検索できる。

ちなみに、redshift上で、日本時間を取得するには、

# select convert_timezone(‘JST’, getdate());

# select dateadd(hour, 9, getdate());

のような方法がある。

以上

awsにtd-agentを導入して、

httpのアクセスログと、phpの任意のログを、

td-agent -> s3 -> redshift

の流れで投入してみた。

awsのEC2ではtd-agentのバージョン2の導入が大変なので、

バージョン1を導入してみた。

インストールは公式ドキュメントにある通り、以下です。

$ curl -L http://toolbelt.treasuredata.com/sh/install-redhat.sh | sh

※v2はcentos7での動作は確認しましたが、awsではv1を利用

いろいろ情報が混在していたのですが、

S3プラグインは最初から入っていて、

フォーマットはjsonでS3に送信することが可能です。

こんな感じ。

/etc/td-agent/td-agent.conf

<source>
    type tail
    path /var/www/test/logs/access.log
    tag apache.test.access
    pos_file /var/log/td-agent/test.access.log.pos
    format /^\[(?<date>.*?)\]\[(?<ip>.*?)\]\[(?<header>.*?)\]\[(?<code>.*?)\]\[(?<size>.*?)\]\[(?<aaa>.*?)\]\[(?<bbb>.*?)\]\[(?<ccc>.*?)\]\[(?<second>.*?)\]$/
</source>
<match apache.test.access>
    type s3
    aws_key_id XXX
    aws_sec_key YYY
    s3_bucket MYBUCKET
    s3_endpoint s3-ap-northeast-1.amazonaws.com

    path logs/httpd/
    buffer_path /var/log/td-agent/httpd/test-access.log
    time_slice_format %Y%m/%d/test-acccess.log.%Y%m%d%H%M
    retry_wait 30s
    retry_limit 5
    flush_interval 1m
    flush_at_shutdown true
    format json
</match>

※httpdアクセスログのフォーマットは、

LogFormat “[%{%Y-%m-%d %H:%M:%S %Z}t][%h][%r][%>s][%b][%{X-AAA}i][%{X-BBB}i][%{X-CCC}i][%T]” hoge

です。

でもって、S3には

test-acccess.log.201501270938_0.gz

こんな感じのログが保存されている。

中身は、

{“date”:”2015-01-27 09:38:10 JST”,”ip”:”182.118.55.177″,”header”:”GET / HTTP/1.1″,”code”:”200″,”size”:”11″,”aaa”:”-“,”bbb”:”-“,”ccc”:”-“,”second”:”0″}

みたいな感じ。

んでもって、

s3上にlogs/httpd/test_access_log_jsonpath.jsonってファイルを作成しておく

{
    "jsonpaths": [
        "$['date']",
        "$['ip']",
        "$['header']",
        "$['code']",
        "$['size']",
        "$['aaa']",
        "$['bbb']",
        "$['ccc']",
        "$['second']"
    ]
}

そして、テーブルを作成しておく。

CREATE TABLE test_access_logs (
    date    datetime sortkey,
    ip        varchar(64),
    header varchar(256),
    code    varchar(16),
    size      varchar(16),
    aaa       varchar(64),
    bbb       varchar(128),
    ccc        varchar(128),
    second varchar(16)
);

この状態でredshift上から、

# COPY test_access_logs
  FROM 's3://MY-BUCKET/logs/httpd/201501/26/'
  credentials 'aws_access_key_id=XXX;aws_secret_access_key=YYY'
  JSON AS 's3://MY-BUCKET/logs/httpd/test_access_log_jsonpath.json'
  GZIP
  COMPUPDATE ON;

ってやれば、あらかじめ作成しておいたテーブルにデータが突っ込まれる。

上記のcreateでは、圧縮オプションはつけていないが、

繰り返しが多い項目に圧縮オプションつけておくと、

かなり削減になる。

【参考】

1000万件のデータを突っ込んだ際、元容量の70%くらいになった。

（あくまで一例ね。）

だた、アクセスログなんかは、比較的繰り返しが多い項目もあるので、

その辺は効果的にやるとよいかもね。

プレビュー版のようですが、

MySQLと互換性をもつRDSが発表されましたね。

詳しくは、こちら。

ちょっと気になるのは、

AmazonのEC2で選択できるAmazonLinuxって、centos6系をベースにカスタマイズされたものだったような。

centosは7から、標準レポジトリにMySQLが外れて、mariadbになってたから、

当面はAmazonLinuxはcentos7には上げないのかね？

EC2とRDSで違うから、問題ないのかもしれないけど、

mariadbもaws（特にRDS）で使えるようになると、今後もっと流行りそうな気がします。