AWS on ララジャパン

とても安いウサギのCDN - Bunny.net

Tue, 25 Jun 2024 03:58:47 +0900

円安の世の中AWSのドル支払は痛いです。最近お客さんのためにコスト削減できないかと調査したところなんと１ヶ月に1,400ドル以上もコストを下げる結果となりました。年間にしたら16,800ドルの節約です！

S3からの画像配信

コスト削減を思い立って、まずお客さんが使用しているAWSサービスのコストを再検討しました。EC2やRDSはもうすべて１年間のリザーブを購入しているので、オンデマンドに比べて30%以上の節約はしています。となると節約できるのは転送量や使用量ベースのコストです。ウェブのアクセスやS3の画像のアクセスを私がコントロールできないので、AWSジャパンの無料のコスト解析のおにいさんたちに相談してみました。しかし、セーブしているところはしっかりセーブしていますよ！と逆に褒められる始末。

そのときに、そのおにいさんに１つ勧められたのは、S3から直接画像を配信するのではなく、そこをオリジンとしてCloudFrontから配信すれば良いということです。CloudFrontを使えばユーザーから一番近いデータセンターから配信されます。でもTokyoとOsakaしか日本にはデータセンターないのではと尋ねると、公開できないけれどあちこちにあるのですよと。しかし小さい日本、そんなに変わるかなと思っていると、今度は１ヶ月の最初の1TBは無料なのですよ、とびきりいい話をくれました。ちなみに、私のお客さんのAWSのS3には、ウェブで閲覧できる画像だけでなく、配信するメルマガに含まれるリンク先の画像も置いています。ここ１年間メールの配信数が増加しているのでS3のアクセスがかなり多いのは確かです。

早速、AWS Cost ExplorerでS3の使用量をチェックしたところ、なんと１ヶ月のS3の使用量は、13,000GB（12TB以上）ありました。最初の1TBが無料はいい話だけれど、削減率はたった10%以下ですか。

ということで、本格的にCDNの市場調査とあいなりました。

Bunny（ウサギ）のCDNサービス

いろいろ調査してわかったのは、CDNに関しては世界的スケールなので英語圏のサービスとなるとAWSより安いのがたくさんあることです。問題は、お客さんのサイトは日本語で日本に住む人だけが対象なので（商品は日本しか発送しません）、CDNのデータセンターが日本にあることが必須条件です。その条件でとびきり安いのが今回紹介するBunnyのCDNサービスです。

まず、どれだけ安いかというと、

アジア向けのスタンダードプランは、１GBあたり0.003ドル！

AWSのS3やCloundFrontは１GBあたり0.114ドルだから、すでに73%以上のディスカウント率です。

さらに、月1TB以上の大量消費のお客様のためにボリュームプランもあります。

超安の１GBあたり0.005ドル！

再度、AWSと比べると95%以上のディスカウントです。

彼らの計算機を使うと、１ヶ月のコストは、

ちなにに、AWS S3のコストは、1,482ドルです。

POPS

CDNのクォリティの基準として、POP (Points of Presence)の数、つまりデータを配信するデータセンターの数の多さというものがあります。

Bunnyのスタンダードプランを見てみましょう。

世界中に123のデータセンターが散らばっています。日本周辺では、Tokyo, Osaka, Seoul, Hong Kong, Taipei, Singaporeがロケーションです。

ボリュームプランでは、POP数はぐっと少なり10となりました。しかし、日本ではTokyoが含まれているではないですか（2023年かららしい）！

日本周辺では、Tokyo, Hong Kong, Singaporeがデータセンターのロケーションです。先に話したように日本に住む日本の対象ならこれでも十分ですね。もちろん、どこのデータセンターもBunnyが一部をどこかから借りているのは確かです。

CDNの設定

早速、登録して使用してみましょう。登録して14日間は無料で使用可能なので試してみましょう。

登録したと仮定して、すでにAWSのS3バケットをお持ちなら、CDNの設定はいたって簡単です。以下のように、Bunnyで希望するCDNのアドレスとS3のアドレスを入れて、High Volumeを選択するだけです。

これで、例えば、https://larajapan.b-cnd.net/test.jpgにアクセスが可能となります。

CDNのPull Zoneを作成すれば、キャッシュの期間の設定、オリジンの認証、画像のクォリティの自動操作、Jpeg画像のwebpへの自動変換、など細かな設定がたくさんありますが、いろいろな対応が可能です。もちろん、CDN Pull Zoneは複数作成可能で、S3バケットごとに作成も可能です。

CDNのキャッシュの削除

お客さんのサイトでBunnyのCDNを使用してみました。使用の前にプログラムが必要だったのは、サイトの商品画像の差し替えでした。以前はS3の画像を取り換えるだけでしたが、今度はそれとともに、Bunnyで対応する画像のキャッシュの削除です。これをやらないとBunnyのキャッシュ保持の期間があるために、すぐには画像が変わりません。もちろん、ブラウザでのキャッシュの問題もありますが。

Bunnyでのキャッシュの削除のプログラムは簡単です。

まず、APIキーが必要です。以下の矢印の部分をクリックしドロップダウンメニューから登録した自分の名前をクリックします。そこのAccount Settingの画面でAPI Keyのメニューをクリックすれば以下のようにキーの取得が可能となります。シンプルなことにBunnyの他のサービスはすべてこのキーひとつで操作可能です。

キーを取得しところで、パージの削除は、Laravelなら以下のようにHttpのファサードを使用します。

$url = 'https://larajapan.b-cdn.net/test.jpg'; //キャッシュ削除の対象のurl
$purgeUrl = 'https://api.bunny.net/purge';　// Bunnyの削除のためのurl

$response = Http::withHeaders([
    'AccessKey' => 'ここにAPIキーを入れる',
    'accept'    => 'application/json',
])->get($purgeUrl, [
    'url'   => $url,
    'async' => 'false',
]);

使用した感想は？

ここが、皆さんが一番知りたいところでしょうね。

お客さんのサイトでS3からの画像配信をBunnyのCDNへ変えて、かれこれ３ヶ月になります。良いニュースは、冒頭で書いた通りの凄いコスト削減となりました。不思議なのは、すべて日本のTokyoのデータセンターから配信されると思いきや、以下のようにTokyoとSingaporeからの配信が半々くらいです。アメリカでの配信があるのは、どうもメルマガに含まれる画像リンク（画像ではない）の画像をGoogleが彼らのデータセンターでキャッシュするからのようです。

さて良いニュースがあれば悪いニュースもあります。それほど悪いニュースという訳でもないのですが、困ったのは、先に書いたBunnyのCDNのキャッシュの削除がうまく行かないときが数回ありました。つまり、お客さんのところでS3の画像の差し替え（同じファイル名で画像の内容を変える）の前に、既存の画像をS3から削除しBunnyのCDNのキャッシュの削除を行っても、このキャッシュがすぐに削除されないのです。ひどいときは削除まで１日近くかかりました。この間差し替えたのにも関わらず、以前の画像が表示されるのです。

この件に関してサポートへ連絡しました。受け答えは即座でいいのですが、いつまでも解決されない。しつこく尋ねると、「海底ケーブルが切れて障害が生じている」と壮大なことを言ってきます。画像の差し替えの頻度はとても低いのですが、お客さんが困っているのでS3からの画像配信に戻しました。サポートからの連絡がなかったのですが、１週間くらい経過してから問題が解決したのでBunnyのCDNに戻しました。もちろんその間はコストありましたが、いざという時に切り替えるようにプログラムを設定しておくのはいいことです。

しかし、それで解決と思いきや最近また発生しました。私の方も準備万端ですでにキャッシュの削除の問題をモニターするプログラムも作成してありますので問題が発生すればすぐわかります。今回は前回よりはベターでキャッシュは最高１時間くらいで削除されました。しかしそれでも１時間はかかりすぎです。今回も対応されないと思いましたが、ダメもとでサポートに連絡しました。しかし今度は担当がいいのか、まじめに取り組んでくれてサーバーの調整をしてくれました。さらに、私がどうモニターしているかも尋ねてくれて、最終的には彼ら自身もTokyoにS3バケットを持ちTokyoのサーバーでキャッシュの削除時間をモニター作成したということです。すぐには復旧となりませんでしたが24時間以内に復旧となりました。前回に比べてかなりのサービスの改善です。まあ、将来はわからないので私のモニターは続きます。

最後に

AWSに比べて削減できたコストは信じられないレベルです。私のお客さんはEコマースのサイトなので配信速度に関してはそうセンシティブはありませんゆえに、速度の比較はしていません。ここはケースバイケースでしょう。私は経験がありませんが、BunnyのCDNにはビデオのストリーミングやS3と似たようなファイル保存のサービスも提供しています。コストが気になるなら無料で試してみるのがベストです。

MySQLレプリカの同期チェック

Sat, 10 Nov 2018 01:56:48 +0900

今回は以前話した、MySQLデータベースのレプリカの話の続きです。

前回はデータベースのレプリカの説明をしましたが、本当にマスターのデータベースと同期しているの？とすぐに疑います。チェックしてみましょう！

調べると、checksum tableというMySQLコマンドが使えるらしい。チェックサムはある計算式をデータに適用してユニークな数を出力するものです。

mysql> use larajapan;
Database changed
mysql> checksum table migrations, password_resets, users;
+---------------------------+------------+
| Table                     | Checksum   |
+---------------------------+------------+
| larajapan.migrations      |  269719583 |
| larajapan.password_resets | 3233767743 |
| larajapan.users           |  669472749 |
+---------------------------+------------+
3 rows in set (0.00 sec)

実行してみるとかなりな速さで結果を出してくれます。私のテストでは500万レコード数もあるテーブルでたったの16秒！

これを、マスターとそのレプリカで、すべてのテーブルに対して実行して比較すれば良いですね。しかし、実際に使用されているDBでは、常に新しいレコードは追加される、更新はある。。。と考えると、ある1時点で両者のデータを比較するのは複雑な作業に見えてきます。

そこで見つけたのが、perconaのツール。perconaはかなり昔からMySQLなどのオープンソースのデータベースの管理をサービスとしている会社です。

準備

AWS EC2では、以下でインストールできます。

$ sudo yum install http://www.percona.com/downloads/percona-release/redhat/0.1-6/percona-release-0.1-6.noarch.rpm

たくさんのツール（perlで書かれている）がインストールされますが、今回必要なツールはマスターとレプリカのデータの同期をチェックする以下のコマンドです。

pt-table-checksum

しかし、このツール、オプションがたくさんあり、ある程度の準備も要る複雑なツールです。私も理解まで何回も何回も試行しました。特に、マスターのDBとレプリカのDBで、MySQLのユーザー名やパスワードが違うとその指定のためにコマンドラインが長くなり、実行にはスクリプトの作成をした方が良いです。

ちなみに、今回は、以前と同様に、マスターはEC2でのMySQL、レプリカは、AWSのRDSのMySQLという仮定です。もちろんレプリカのサーバーにはsshできないので、マスターで実行します。

準備として、以下のMySQLの情報を用意してください。

マスターのユーザー名マスターのパスワードレプリカのユーザー名レプリカのパスワード

マスターやレプリカのMySQLユーザーは以下の権限が必要ですが、以下のように特別に作成しなくとも、通常はrootのような管理権限のあるユーザーで足ります。

mysql> GRANT SELECT ON larajapan.* TO 'checksum_user'@'%' IDENTIFIED BY 'checksum_password';
mysql> GRANT REPLICATION SLAVE,PROCESS,SUPER ON *.* TO `checksum_user`@'%';
mysql> GRANT ALL PRIVILEGES ON percona.* TO `checksum_user`@'%';

次に、ツールが出力するデータを保存するためのデータベース（percona）とテーブル（checksums）を作成します。

mysql> create databaser percona;
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'databaser percona' at line 1
mysql> create database percona;
Query OK, 1 row affected (0.00 sec)

mysql> use percona
Database changed
mysql> CREATE TABLE checksums ( db CHAR(64) NOT NULL, tbl CHAR(64) NOT NULL, chunk INT NOT NULL, chunk_time FLOAT NULL, chunk_index VARCHAR(200) NULL, lower_boundary TEXT NULL, upper_boundary TEXT NULL, this_crc CHAR(40) NOT NULL, this_cnt INT NOT NULL, master_crc CHAR(40) NULL, master_cnt INT NULL, ts TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (db, tbl, chunk), INDEX ts_db_tbl (ts, db, tbl) ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
Query OK, 0 rows affected (0.01 sec)

マスターとレプリカの両方で作成が必要ですが、ツールの最初の実行でマスターでは自動的に作成されます。

実行

ここで、まず実行してみましょう。運が良ければここで以下のような出力となります。

$ pt-table-checksum -d larajapan -u checksum_user -p checksum_password --recursion-method processlist --no-check-binlog-format --no-check-replication-filters
Checking if all tables can be checksummed ...
Starting checksum ...
            TS ERRORS  DIFFS     ROWS  DIFF_ROWS  CHUNKS SKIPPED    TIME TABLE
11-09T07:54:37      0      0        2          0       1       0   1.019 larajapan.migrations
11-09T07:54:37      0      0        1          0       1       0   0.017 larajapan.password_resets
11-09T07:54:37      0      0        5          0       1       0   0.014 larajapan.users

ERRORSとDIFFSの列、これが皆ゼロならマスターとレプリカは同期しています。心配なしです。

さて、どうしてレプリカのホスト情報をコマンドラインに入れていないのにレプリカのチェックが可能なのでしょう？

それは、–recursion-method processlistの部分です（デフォルトでは、ここはprocesslist, hostsとなるのですが、私のトライではhostsの部分でエラーになりました)。

MySQLのshow processlistコマンドを実行すると、

mysql> show processlist;
+-----+------------+-----------------------------------------------+--------------+-------------+-------+-----------------------------------------------------------------------+------------------+
| Id  | User       | Host                                          | db           | Command     | Time  | State                                                                 | Info             |
+-----+------------+-----------------------------------------------+--------------+-------------+-------+-----------------------------------------------------------------------+------------------+
|   2 | slave_user | ip-10-0-1-32.us-west-2.compute.internal:64617 | NULL         | Binlog Dump | 14651 | Master has sent all binlog to slave; waiting for binlog to be updated | NULL             |
| 918 | root       | localhost                                     | NULL         | Query       |     0 | NULL                                                                  | show processlist |
| 919 | root       | localhost                                     | larajapan_wp | Sleep       |     0 |                                                                       | NULL             |
+-----+------------+-----------------------------------------------+--------------+-------------+-------+-----------------------------------------------------------------------+------------------+
3 rows in set (0.00 sec)

レプリカのホスト情報が出て来るのでそれを利用しているのです。

また、ここでは、レプリカでのMySQLのユーザー名とパスワードは、マスターと同じと仮定しています。これが違うなら、

–slave-user admin –slave-password pass

の指定がコマンドラインで必要となります。

本当にチェックしている？

ひとまず成功したところで、本当に差分を出してくれるか興味あるところです。レプリカにおいて、情報変えてみましょう。

mysql> delete from users where id = 6;
Query OK, 1 row affected (0.01 sec)

レプリカのusersのテーブルのレコードを１つ削除しました。

そして再度実行です。

$ pt-table-checksum -d larajapan -u checksum_user -p checksum_password --recursion-method processlist --no-check-binlog-format --no-check-replication-filters
Checking if all tables can be checksummed ...
Starting checksum ...
            TS ERRORS  DIFFS     ROWS  DIFF_ROWS  CHUNKS SKIPPED    TIME TABLE
11-09T08:18:43      0      0        2          0       1       0   0.021 larajapan.migrations
11-09T08:18:43      0      0        1          0       1       0   0.017 larajapan.password_resets
11-09T08:18:43      0      1        5          0       1       0   0.019 larajapan.users

チェックしてくれましたね。DIFFSに1が表示されているのがそうです。

デバッグ

このコマンドラインでは、本当にたくさんのオプションがあるのでいろいろなチェックが可能なのですが、エラーが理解不可能なときは、以下のようにデバッグモードを使ってみるのが良いです。stderrに情報がたくさん出力されるので以下のようにファイルにキャプチャする必要あります。

$ PTDEBUG=1pt-table-checksum > FILE 2>&1

また、オプションのデフォルトも把握することも大事です。

$ pt-table-checksum --help

の実行でデフォルトの情報が得られます。

MySQLデータベースのレプリカにAWS RDSを利用

Tue, 02 Oct 2018 11:33:08 +0900

昔からMySQLでレプリカ（複製）が作成できる機能の存在は知っていたけれど、大きなスケールのサイトで、ロードバランスに使用される読み込み専門のレプリカとして使われるだろうな、くらいに思っていました。しかし、最近はこれがほぼリアルタイムに近いバックアップとしても使える可能性を知り、早速取り組んだ次第です。

AWS RDS

MySQLのデータベースのレプリカを作成するには、もちろんレプリカのソースとなるマスターのMySQLサーバーがあります。私のケースでは、LAMPなのでマスターはAWSのEC2のマシンに常駐サービスの１つとして存在しますが、さてレプリカはどこに置いたら良いでしょう？

レプリカと言ってもこれもまたMySQLサーバーが必要なので、新規のEC2のマシンを用意して、そこにレプリカを置くことになります。しかし単にレプリカのためだけの目的で、もう１つマシンを用意するのはちょっとです。将来においてマシンのOS更新とかバックアップの設定とかメンテが面倒です。そこで注目したのは、AWSのRDSです。今時流行りのSAAS（Software AS Service）です。

今まで使ったことがないAWSのサービスなので親交を深める良い機会です。と思って取り組みましたが、はっきり言って、手順が複雑です。数日かけて何回も失敗して、レプリカのＤＢを何回も作成し直して。。。ということで、忘れないように貴重な（少なくとも私には）手順の作成となりました。

１．レプリカのDBインスタンスの作成（AWS）

まずは、AWS RDSのページへ行き、レプリカを保存するDBインスタンス（マシン）の作成です。以下へのアクセスは、AWSへのアカウントへのログインが必要です。

https://ap-northeast-1.console.aws.amazon.com/rds/home?region=ap-northeast-1#launch-dbinstance:

その後以下のステップを経て、DBインスタンスの作成です。AWSでは「データベースの作成」という言葉が使用されていますが、実際は、DBインスタンス、つまりマシンの作成です。１つのDBインスタンスで、いくつものデータベースを作成が可能ですので。混乱しないように注意してください。

ステップ１　エンジンの選択

ここでは、「エンジン」にはMySQLを選択します。また、最初のテスト段階では必ず「無料バージョン」を選択するのを忘れずに。

ステップ２ DB詳細の指定

ここでは、とくに「DBエンジンのバージョン」に注意してください。なるべくマスターと同じMySQLのバージョンの使用を薦めます。すでに「無料利用枠」を選択しているなら、「DBインスタンスのクラス」は、一番小さいマシンのt2.microしか選択できません。他のオプションも選択不可となっています。下の画面には表示されていませんが、「DBインスタンの識別子」や「マスターユーザーの名前」と「マスターパスワード」の入力も必要です。

ステップ３詳細設定の指定

この画面での注意としては、「パブリックアクセシビリティ」では「いいえ」を選択すること。いろいろなケースがありますが、今回はマスターとのコミュニケーションをプライベートのIPアドレスを通して行うゆえにです。さらに、「アベイラビリティーゾーン」では、必ずマスターとは違うゾーンを選ぶことです。ゾーンは物理的に独立した場所にあるデータセンターなので、片方で火事などが起こってデータを失ってもも片方ではＯＫという仮定です。ここでは触れませんが、このためにVPCのサブネットを前もって作成する必要があるかもしれません。

完了！

これでDBインスタンス作成の設定が完了です。これから数分間でDBインスタンスへのアクセスが可能となります。

２．マスターでの設定と作業

レプリカのDBインスタンスを作成したところで、今度はマスターでの設定です。いくつかの作業があります。

レプリカのログの作成

マスターのMySQLサーバーにおいて、レプリカのためのログの作成が必要です。このログは、マスターのDBで実行されるすべてのSQL文を皆バイナリのファイルに入れたようなものです。それをレプリカが定期的にのMySQLサーバーが取りに行き、レプリカでそれらを実行してマスターと同期するわけです。

ログのファイルは以下のように番号が付いたファイルとして作成されます。最新のものほど大きい番号となります。

$ ls -1
mysql-bin.000001
mysql-bin.000002
mysql-bin.000003
mysql-bin.index

このログ作成の設定は、マスターのマシンの/etc/my.cnfで行います。

/etc/my.cnf

...
[mysqld]
...
server-id=1	
binlog-do-db = test1_db
binlog-do-db = test2_db
log-bin=/var/lib/mysql/logs/mysql-bin.log	
...

server-idはユニークな数字のIDでレプリカのIDとは重複しないようにしてください。私の設定ではAWS RDSのレプリカのserver-idは非常に大きな数字（例：2092607505）なので小さい数字ならとりあえずＯＫです。binlog-do-dbではレプリカを作成したいDB名を指定します。複数のときは例のように複数行で指定します。log-binは、ログファイルの場所とそのファイル名のフォーマットを指定します。

設定後に、MySQLサーバーをリスタートします。もちろんその前にLaravelのアプリなら、

$ php artisan down

や、クロンジョブなどのサービスをダウンさせること忘れないでください。

リスタート後に、MySQLのコマンドで、マスターのステータスを見ることができます。

		
mysql> show master status;

+------------------+----------+----------------------------------+------------------+
| File             | Position | Binlog_Do_DB                     | Binlog_Ignore_DB |
+------------------+----------+----------------------------------+------------------+
| mysql-bin.000001 |      107 | test1_db, test2_db               |                  |
+------------------+----------+----------------------------------+------------------+
1 row in set (0.00 sec)

この時点では、Laravelのアプリもクロンジョブも再開してＯＫです。

レプリカのためのDBユーザーの作成

今度は、レプリカのMySQLがマスターのログからデータを取得するために、マスターにおいてDBユーザーを作成します。

$ mysql -u root -p
...
mysql> GRANT REPLICATION SLAVE ON *.* TO 'slave_user'@'%' IDENTIFIED BY 'testtest';
mysql> FLUSH PRIVILEGES;

最初の行は、slave_userがtesttestのパスワードでログインして複製の情報を取得することをＯＫしています。ここではどこのホストからでもマスターのどのデータベースの複製がＯＫという設定です。

レプリカからマスターへのアクセス制限

ここではインスタンス（マシン）レベルで、レプリカがマスターにアクセスできる設定をします。まず、レプリカのDBインスタンスのＩＰアドレスが必要です。DBインスタンスの情報画面で、まず「エンドポイント」のホスト名を取得します。

それを、シェルでpingします。

$ ping db1.xxxxxx.us-west-2.rds.amazonaws.com
PING db1.xxxxxx.us-west-2.rds.amazonaws.com (10.0.1.32) 56(84) bytes of data.

そのIPアドレスを今度は、AWSのコンソールの「セキュリティグループ」で以下のように、ポート3306に対してオープンします。このセキュリティグループはマスターで使用されているものです。

レプリカの設定

もうゴールは近しです。マスターのデータをレプリカにコピーしてレプリカの開始です。

マスターからレプリカへのアクセスの設定

先ほどとは逆に、今度はマスターからレプリカへアクセスできるための設定です。AWSコンソールで先と同様な作業ですが、今度は、レプリカの「ステップ３詳細設定の指定」の画面で作成したあるいは指定したセキュリティグループにおいて、マスターからのアクセスを許します。

画面での、10.0.0.137は、マスターのプライベートのIPアドレスです。

マスターのデータをレプリカにコピーして複製を開始

まず、マスターで対象のデータベースのデータをエクスポートします。

$ mysqldump -u root test1_db --master-data -p > test1_db.sql

次には、レプリカにアクセスしてそのデータをレプリカにインポートします。

$ mysql -u root -h db1.xxxxxx.us-west-2.rds.amazonaws.com -p
...
mysql> source test1_db.sql
...

引き続いて、レプリカのMySQLコマンドでマスターを設定して、複製を開始します。

mysql> CALL mysql.rds_set_external_master ('10.0.0.137', 3306, 'slave_user', 'testtest', 'mysql-bin.000001', 107, 0);		
mysql> CALL mysql.rds_start_replication;

最初の行の、‘mysql-bin.000001’, 107の数字は、test_db1.sqlのファイルの最初のページから情報が得られます（以下）。

--
-- Position to start replication or point-in-time recovery from
--

CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=107;

エクスポートの時点でのどのログファイル、どの位置かがこれでわかるため、エクスポートからインポートの間にどんなに時間が開いても、どんな変更があっても、そこの場所から複製を開始してマスターと同期できるわけです。

最後に、レプリカの複製の状況を見たいときは、コマンドshow slave statusを実行します。ここで問題があれば、エラーとして表示されますので注意をしてください。

mysql> show slave status\G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 10.0.0.137
                  Master_User: slave_user
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000003
          Read_Master_Log_Pos: 8148599
               Relay_Log_File: relaylog.002965
                Relay_Log_Pos: 658
        Relay_Master_Log_File: mysql-bin.000003
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
              Replicate_Do_DB: 
          Replicate_Ignore_DB: 
           Replicate_Do_Table: 
       Replicate_Ignore_Table: mysql.rds_sysinfo,mysql.rds_history,mysql.rds_replication_status
      Replicate_Wild_Do_Table: 
  Replicate_Wild_Ignore_Table: 
                   Last_Errno: 0
                   Last_Error: 
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 8148599
              Relay_Log_Space: 1357
              Until_Condition: None
               Until_Log_File: 
                Until_Log_Pos: 0
           Master_SSL_Allowed: No
           Master_SSL_CA_File: 
           Master_SSL_CA_Path: 
              Master_SSL_Cert: 
            Master_SSL_Cipher: 
               Master_SSL_Key: 
        Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error: 
               Last_SQL_Errno: 0
               Last_SQL_Error: 
  Replicate_Ignore_Server_Ids: 
             Master_Server_Id: 1
1 row in set (0.00 sec)

マスター側では、レプリカのRDSからログを取得に来ているのが以下でわかります。

$ mysql -u root -p
...
mysql> show processlist;
+--------+------------+-----------------------------------------------+------+-------------+--------+-----------------------------------------------------------------------+------------------+
| Id     | User       | Host                                          | db   | Command     | Time   | State                                                                 | Info             |
+--------+------------+-----------------------------------------------+------+-------------+--------+-----------------------------------------------------------------------+------------------+
|  54532 | slave_user | ip-10-0-1-32.us-west-2.compute.internal:47756 | NULL | Binlog Dump | 440946 | Master has sent all binlog to slave; waiting for binlog to be updated | NULL             |
| 102446 | root       | localhost                                     | NULL | Query       |      0 | NULL                                                                  | show processlist |
+--------+------------+-----------------------------------------------+------+-------------+--------+-----------------------------------------------------------------------+------------------

Laravel 5.3　AWS S3にファイルをアップロード

Sun, 09 Oct 2016 04:38:28 +0900

アップロードしたファイルの保存のメソッドがLaravelで5.3で少し変わりました。ここでそれらの情報更新とともに、AmazonのストレージサービスS3にファイルをアップロードする仕方を紹介します。

まず、準備から、

パッケージの追加と設定

コマンドラインで以下の実行が必要です。

composer require league/flysystem-aws-s3-v3 ~1.0

これにより、

config/filesystems.php

の設定ファイルが作成されます。

return [
    'default' => 'local',
    'cloud' => 's3',

    'disks' => [

        'local' => [
            'driver' => 'local',
            'root' => storage_path('app'),
        ],

        'public' => [
            'driver' => 'local',
            'root' => storage_path('app/public'),
            'visibility' => 'public',
        ],

        's3' => [
            'driver' => 's3',
            'key' => 'AWSのキー',
            'secret' => '秘密のキー',
            'region' => '地域のコード',　// 日本なら、ap-northeast-1
            'bucket' => 'バケット名'
        ],
    ],
];

localは、使用しているサーバーのストレージのことです。

rootは、Laravelをインストールしたディレクトリのサブディレクトリ、storage/appの場所となります。

publicは、ウェブユーザーにアップロードしたファイルをパブリックに紹介する場所です。

以下の実行で、public/storageが、storage/app/publicにリンクされます

php artisan storage:link

例えば、アップロードされたファイルは、

storage/app/public/mario.jpg

に保存され、

http://localhost/public/storage/mario.jp

で閲覧できるということです。

s3のkey, secret, region, bucketの指定は必須です。これらは、Amazonのウェブサービスのコンソールで取得できます。

これで設定終わりです。

ファイルのアップロードのプログラム

簡単なファイルのアップロードのプログラムを書いてみます。

まず、routeの設定から、

routes/web.php

    Route::get('upload', 'UploadController@create');
    Route::post('upload', 'UploadController@store');

これで、

http://localhost/upload

にアクセス可能です。

次にコントローラ、

app/Http/Controllers/UploadController.php

namespace App\Http\Controllers;

use Illuminate\Http\Request;

use Storage;

class UploadController extends Controller
{
    public function create()
    {
        return view('upload');
    }

    public function store(Request $request)
    {
        $filename = $request->file('image')->getClientOriginalName();　//アップロードしたファイル名を取得

        $path = $request->file('image')->storeAs('public', $filename);

        return back()->with('filename' => $filename);
    }
}

storeAs(‘public’, $filename);

この最初のパラメータは、ファイルを保存するディレクトリ名です。先のconfig/filesystems.phpの設定で、storage/appがルートのディレクトリゆえに、上のコードではstorage/app/publicにファイルが保存されることになります。

ファイル名がmario.jpgであれば、

storage/app/public/mario.jpg

と保存されます。

ファイルをアップロードするフォームのブレードは、

upload.blade.php

@extends('layouts.app')

@section('content')
<div class="container">
    <div class="row">
        <div class="col-md-8 col-md-offset-2">
            <div class="panel panel-default">
                <div class="panel-heading">Media Upload</div>
                <div class="panel-body">
                    <form class="form-horizontal" role="form" method="POST" action="{{ url('upload') }}" enctype="multipart/form-data">
                        {{ csrf_field() }}

                        <div class="form-group">
                            <label for="image" class="col-md-4 control-label">File</label>

                            <div class="col-md-6">
                                <input id="image" type="file" name="image">
                            </div>
                        </div>

                        <div class="form-group">
                            <div class="col-md-6 col-md-offset-4">
                                <button type="submit" class="btn btn-primary">
                                    Upload
                                </button>
                            </div>
                        </div>
                    </form>
                </div>
            </div>
        </div>
    </div>
    <div class="row">
        <div class="col-md-8 col-md-offset-2">
            <div class="panel panel-default">
                <div class="panel-body">
                @if (session('filename'))
                    <h4>Local</h4>
                    <img src="{!! asset('storage/'.session('filename')) !!}">
                @endif
                </div>
            </div>
        </div>
    </div>
</div>
@endsection

先の例で、ファイル名が、mario.jpgならば、

asset(‘storage/’.session(‘filename’))

は、

http://localhost/public/storage/mario.jpg

のようになるわけです。

ファイルをアップロードした後の画面はこんな感じです。

Ｓ３に画像をアップロード

さて、サーバーにアップした画像を、今度はS3にアップするのですが、これはconfig/filesystems.phpの設定が済んでいれば、本当に簡単です。

コントローラのstoreメソッドにたったの２行追加するだけです。

   public function store(Request $request)
    {
        $filename = $request->file('image')->getClientOriginalName();

        $path = $request->file('image')->storeAs('public', $filename);

        $contents = Storage::get('public/'.$filename); //ファイルを読み取る
        Storage::disk('s3')->put($filename, $contents, 'public'); // Ｓ３にアップ
 
        return back()->with(['filename' => $filename]);
    }

>put($filename, $contents, ‘public’)

ここのpublicに注意してください。これがないと一般には公開されません。

以下のAWSのコンソールの赤箱の部分がそれにより追加されます。

先の画面にＳ３から直接画像を表示したいなら、ブレードに以下の変更を。

    <div class="panel-body">
    @if (session('filename'))
       <h4>Local</h4>
       <img src="{!! asset('storage/'.session('filename')) !!}">
       <h4>S3</h4>
       <img src="{!! Storage::disk('s3')->url(session('filename')) !!}">
    @endif
    </div>

S3の以下のURLが生成されます。

https://s3-us-west-2.amazonaws.com/demo53/mario.jpg

us-west-2は、設定に使用した地域コードです。日本ならap-northeast-1となります。