読者です 読者をやめる 読者になる 読者になる

プログラマでありたい

おっさんになっても、プログラマでありつづけたい

Amazonプライム・フォト(cloud drive)で、写真のバックアップ。或いはAmazonプライムが凄い

 動物園のカバの方が、もう少し活発に動いているのではないかと思われるくらい、怠惰に過ごしているゴールデンウィークです。時間があるので色々とやろうとしているのですが、気がつけば寝てばかりという現実ありますよね。そんな中で唯一生産的なことをしたのが、自宅のMac miniに入れた写真の整理です。

ホームメディアサーバーとしてのMac mini



 以前紹介しましたが、我が家のMac miniはメディアサーバーとしての役割を果たしています。テレビやホームシアターシステムにつないで、音楽や映画を流すためです。が、AmazonプライムにプライムビデオやPrime Musicがついたことで、その役割はほぼFire TVに奪われました。

データの保管先としてのMac mini



 そんな状況で、残された役割はデータの保管先としてのMac miniです。iPhoneとNexusのバックアップ先として利用しています。以前は、プライベートの開発や収集したデータのバックアップ際にも利用していました。しかし、それらの殆どがクラウドもしくはサービス上に保存されている為、バックアップすべきデータとして重要なのは写真だけということに気が付きました。ということで、Mac miniにためられた写真の保管先の検討です。
 一部のデータは、AWS S3に保存されアーカイブ化されています。自動実行するように設定していなかったので、今回自動化しようとしました。が、考えてみると、S3上に置いた写真データは一度も見返したことがなかったです。また、Amazon Primeに入っていると、cloud driveの機能の一部としてAmazonプライム・フォトが容量無制限で使えます。ということで、Amazonプライム・フォトに鞍替えすることにしました。

Amazonプライム・フォトの設定



 Mac版を利用しましたが、設定は簡単です。インストーラーをダウンロードして、アプリインストール後にサインアップするだけです。そして、任意のファイルをアップロードします。

インストーラーからインストール。ダブルクリックするだけです。
f:id:dkfj:20160505123218p:plain

アカウントの設定。Amazonのアカウントです。
f:id:dkfj:20160505123227p:plain

アップロード対象の設定。好きなものを選びます。私は写真のみを対象としましした。
※スクリーンショットはサブのMabbook Airの設定時のものです。
f:id:dkfj:20160505123231p:plain

アップロードが開始したら、後は待つだけです。
f:id:dkfj:20160505123235p:plain

アップロード済みのものは、Webからも閲覧できます。
f:id:dkfj:20160505123222p:plain

Amazonプライムについて



 改めて最近のAmazonプライムの拡充っぷりは凄いと思います。ビデオと音楽が聴き放題で、写真の保存も無制限。月一冊まで、Kindle本も無料で読めます。特典が配送が速いだけだった時代に比べると、隔世の感があります。
 年会費3,980円でこのサービスは素直に凄いと思います。囲い込み完了したら、米国みたいに値上げするという話もありますが、その時はその時に損得を考えれば良いでしょう。


AWSアプリ本の20%ポイント還元セールのお知らせ 『Amazon Web Services クラウドネイティブ・アプリケーション開発技法』

 4/20に発売されて、出だし好調の『Amazon Web Services クラウドネイティブ・アプリケーション開発技法』です。朝起きると、AmazonでKindle版が20%のポイント還元セールの対象となっていました。
 紙版の税込み価格は3,974円とかなり高い部類に入りますが、Kindleだと3,577円と10%オフで397円の割引された値段となっています。今だと更に20%ポイント還元なので、20%分の715ptが還元されます。紙版に較べて、実質的に1,112円分お得です。是非ご検討ください。

Kindle版のメリット



 紙の本に較べて、Kindle版は次のようなメリットがあります。

  • (物理的に)軽い
  • 増刷・改訂時の修正がアップデートで手に入る

 1つ目のメリットとしては、物理的に軽いということです。紙版は鈍器のような本と言われることがあるくらい分厚いです。先日、配るために紙袋に4冊いれて歩いていました。他の荷物とあいまって、手が千切れるかというくらい重かったです。Kindleは、何冊いれても軽いです。
 2つ目のメリットとしては、増刷や改訂時に内容が修正された場合にKindle版であればアップデートすれば最新のものが手に入るということです。これは結構大きいと思います。増刷のタイミングはいつになるか解りませんが、可能なかぎり最新の状態で修正していこうと思います。変化の速い分野なので、これは嬉しいかもしれません。
※なお出版元のSBクリエイティブのWebサイトにも改定情報は掲載されます。

Kindle版の注意点



 現状提供している形式は、固定長フォーマットです。つまりPDFを画像として取り込んでいるものです。その為にサイズが大きく、何と140MBもあります。その為Kindle版は、物理的には軽いけど、論理的には重い本となっています。また、電子書籍のメリットである検索やハイライトができません。何とかして欲しいですね。。。

その他



 この本は、Amazon上のカテゴリではクラウドWeb構築・管理に分類されています。現時点では、どちらのカテゴリでも1位です。出版社に聞いた所、このカテゴリ管理は完全にAmazonに管理されていて出版社の意向も反映されないようです。

f:id:dkfj:20160505112031p:plain

 モバイルプログラミングのカテゴリにも属して欲しいのですが、何か方法はないものでしょうか?Amazonの場合、機械学習のデータを重視しているので、モバイルプログラミングに属するホント一緒に購入された場合や、モバイルプログラミングカテゴリから検索で本書にたどり着く人が多ければ反映されるんじゃないかなぁと思っています。誰か知っている人いるでしょうか?




See Also:
アプリケーションエンジニア向けのAWS本を書きました
Amazon Web Services クラウドネイティブ・アプリケーション開発技法の目次
Amazon Web Services クラウドネイティブ・アプリケーション開発技法のサンプルアプリケーションをGitHubで公開しました
エンジニアよ、越境しよう!!クラウド時代のエンジニア像
『Rubyによるクローラー開発技法』を書きました
『Amazon Web Services パターン別構築・運用ガイド』を書きました

Amazon AuroraとMariaDB Connector/Jの話

 今月創刊したクラウド専門誌の日経クラウドファースト。その特集の1つが、Amazon Auroraです。私も、その特集の執筆に協力させて頂きました。

itpro.nikkeibp.co.jp

 その中で、AuroraとMariaDB版のConnector/Jについて少し触れています。個人的にはMariaDB版のConnector/Jは、設計思想や実装面から将来性があり、かなり面白い製品と思っています。せっかくの機会なので、少し紹介します。

Auroraのクラスタ・エンドポイントとインスタンス・エンドポイント



 MariaDBのConnector/Jの話をする前に、まずAuroraに接続するためのエンドポイントの説明をします。Auroraには、クラスタ・エンドポイントとインスタンス・エンドポイントの2種類のエンドポイントを持っています。
 インスタンス・エンドポイントは、Auroraの各インスタンスに直接接続する為のエンドポイントです。立ち上げたインスタンスの数のぶんだけ、エンドポイントが作られます。これに対して、クラスタ・エンドポイントは、Auroraのマスターノードに接続する為のエンドポイントです。マスターノードのインスタンス・エンドポイントへのDNSのエイリアスになっていて、フェイルオーバーが発生すると、新しいマスターノードのインスタンス・エンドポイントへ切り替えられます。図示化すると、下記のような形になっています。

f:id:dkfj:20160427080205p:plain

 Auroraの呼び出し元としては、クラスタ・エンドポイントのみ記述しておけば良いという形となります。

MariaDB版Connector/Jの接続方法



 これに対して、MariaDB版Connector/Jは全く別のアプローチをしています。何とクラスタ・エンドポイントを一切利用せず、インスタンス・エンドポイントを全て登録するという形になっています。

f:id:dkfj:20160427080210p:plain

 そして、MariaDB Connector/Jの方で、どのインスタンスがマスターノードか把握して、そこにクエリーを投げるという形になっています。どうしてこのような構造になっているのかというと、高速なフェイルオーバーの為です。前述の通り、Auroraのクラスタ・エンドポイントの切り替えは、DNSを利用しています。そのTTLは5秒なので、障害検知後の切り替えは最低5秒は掛かります。それより短縮する為のアプローチなのです。
 ちなみに、MariaDB Connector/Jがマスターかスレイブか判断する方法としては、InnoDBのステータスを見ています。リードレプリカの方は、書き込み禁止のステータスがかえってくるのでそこを判断しているようです。

MariaDB版Connector/Jの可能性



 意外に単純な仕組みですが、これは結構面白いアーキテクチャです。現在は、フェイルオーバーの高速化のためだけの仕組みになっています。しかし、Connector/Jとしては、どれがマスターでどれがスレイブか把握できているということになります。そうであれば、Connector/J自身でクエリを判断して、更新系であればマスターに参照系であればリードレプリカにと振り分けが出来るはずです。リードレプリカへの振り分けは、アプリの実装含め悩みどころなので夢が広がりますね。

まとめ



 今回の特集の中で、MariaDB Connector/Jの話はごく一部です。これ以外にもAuroraのアーキテクチャ面の解説や耐障害性など、かなり濃い話をいろいろ書いています。Auroraを使う前に読んでおくと、結構理解が進んで良いと思います。
 ちなみに日経クラウドファーストの執筆陣は、cloudpackさんやサーバーワークスさん、クラスメソッドさん、TISさんにNRIとAWSのプレミアコンサルティングパートナーが揃っています。かなり濃いメンツで、企画のための会議にもかなりディープな情報が出てきています。ということで、興味がある人は日経クラウドファーストの購読を是非よろしくおねがいします。ついでに、Amazon Web Services クラウドネイティブ・アプリケーション開発技法もよろしくお願いします。

itpro.nikkeibp.co.jp


See Also:
アプリケーションエンジニア向けのAWS本を書きました
Amazon Web Services クラウドネイティブ・アプリケーション開発技法の目次
Amazon Web Services クラウドネイティブ・アプリケーション開発技法のサンプルアプリケーションをGitHubで公開しました
エンジニアよ、越境しよう!!クラウド時代のエンジニア像
『Rubyによるクローラー開発技法』を書きました
『Amazon Web Services パターン別構築・運用ガイド』を書きました

AWSのストレージよもやま話 s3,ebsからStorage Gateway,EMRFSまで

 昨日、VPCの話を書いていて思い浮かんだのがストレージの話です。AWSのストレージといえば、S3とEBSが中心です。しかし、オンプレからの移行ではNAS相当のものがなくて、先人たちは色々と試行錯誤してきました。また、製品群を見返すとAWS自身も相当いろいろ検討して苦労したのだなと解ります。という訳で、何の役に立たないAWSのストレージの四方山話です。

s3fs



 事実上無限の容量を持つS3をファイルシステムとして扱えるs3fs。誰しも一度は夢をみて、夢敗れるファイルシステムではないでしょうか。これは純正のライブラリではなく、サードパーティ製です。構造としては下記の通りで、問題点としてはメタデータ(ファイル一覧や個々のファイルの日付・サイズ等の情報)を持たない点です。よって使い方によっては、かなり遅いです。また初期のものはメモリーリークとか多く、定期的な再起動が必要だったりします。

f:id:dkfj:20160426080823p:plain

みんな薄々と気が付いていると思いますが、s3fsが悪いのではないです。s3fsに夢を見過ぎた我々が悪いのです。

Storage Gateway



 最近では、EBS自体が16TBまで作れるので、EBS単体で大容量ファイルサーバの構築も簡単になっています。昔は1TBまでだったので、仮想ボリュームとして束ねたり、Storage Gatewayの利用を検討したものです。Storage Gatewayは、S3をストレージ・ボリュームとして扱えるもので、当初はオンプレからクラウドへバックアップする際に利用することが多かったです。Storage Gatewayは幾つかタイプがあって、Gateway-Cached Volumeは、EBS上にキャッシュがなければStorage Gateway経由でS3に取りに行くという構造になっています。そこに夢を見たのですよ。

f:id:dkfj:20160426080846p:plain

 個人的には、アーキテクチャとして中々良いのではと思っています。ただ1つ残念なのがというか、致命的だったのがメタ情報自体もStorage Gateway側(S3)に持っている為に、キャッシュに載っていなくて大量ファイルがあるようなディレクトリを参照した日には待てど暮らせど応答が返ってこないということになります。
 今だとEBSの容量が大きくなったので、Cached volumeではなくゲートウェイ保管型の方でも良いような気もしてきています。最近は、あまり触ることもなくなりましたが、地味に色々な所で活躍していると思います。

EMRFS(Elastic MapReduce FileSystem)



 EMRFSは、その名の通りEMR(Elastic MapReduce)用のファイル・システム。S3を束ねてファイルシステムとして利用できる。メタ情報は、S3ではなくDynamoDBに保存するのがポイントになっている。Consistent Viewとして整合性のあるビューを提供されます。

f:id:dkfj:20160426080850p:plain

 これをサービスとして出したらいいのじゃないのと思う人は多いでしょう。ただ、EMRで利用すること前提で、知名度低いです。

EFS(Elastic File System)



 AWSのNASタイプのファイルサービスとして鳴り物入りで登場したのがEFSです。恐らく全てのAWSユーザが待ち望んでいたサービスではないでしょうか。S3のように従量課金制で、容量も拡張型です。複数のインスタンスからマウントできます。

f:id:dkfj:20160426080840p:plain

 しかし、待てど暮らせど状態がプレビューから変わりません。また、アーキテクチャが全然公開されず実体は謎のままです。このサービスは我々の願望が生み出した夢で、現実には発表されていないのではとたまに疑っています。

まとめ



 ちょっと解説が大変なので省略しますが、これ以外にもRDS for Auroraで使われているQuorum型のストレージがあります。ストレージは設計の肝になることが多いので、よく考えてみましょう。個人的な結論としては、アプリを改修してS3ベースに出来るのが一番幸せです。なかなかそう出来ないのが、現実なんですよね。
 最近だしたAmazon Web Services クラウドネイティブ・アプリケーション開発技法には、EC2やEBSに頼らないシステムの構築方法を紹介しています。ぜひ御覧ください。


See Also:
アプリケーションエンジニア向けのAWS本を書きました
Amazon Web Services クラウドネイティブ・アプリケーション開発技法の目次
Amazon Web Services クラウドネイティブ・アプリケーション開発技法のサンプルアプリケーションをGitHubで公開しました
エンジニアよ、越境しよう!!クラウド時代のエンジニア像
『Rubyによるクローラー開発技法』を書きました
『Amazon Web Services パターン別構築・運用ガイド』を書きました

VPCとクラウドネイティブ

 長くAWSを使っていると気が付かなくなるのだけど、VPCというのはAWSを始めようとする際の1つの関門になっています。こういう事を書くと、ネットワークの知識があればVPCやサブネットの構築なんて簡単と反論されるかもしれません。どの辺りが解りにくいのか、順番に見てみましょう。

AWSネットワークとVPCネットワーク



 まずAWSのネットワークと、VPCのネットワークの違いを見てみましょう。VPCは、(便宜的に名付ける)AWSネットワークの中に、仮想的に作られたネットワークです。広大なAWSネットワークの海の隅っこにブイと網で囲まれた遊泳場のような場所がVPCです。まずこの概念が解りにくいのです。
 次にAWSのサービスの中には、VPC内のみに利用できるサービスとVPC内にいれられないサービス、そして中にも外にも作れるサービスの3種類があります。更に、VPC内には作れないけど、VPCにエンドポイント(接続ポイント)が作れるものがあります。一度、図示してみます。
f:id:dkfj:20160425080634p:plain

 VPC/非VPCのサービスがあるために、利用しようとしているサービスを利用する場合に、どう始めればよいのか解らないという声を聞いたことがあります。VPCを作ってから始めるのか、そのまま利用できるのか。また非VPCのサービスをVPC内から利用するにはどうすれば良いのかなどです。
 私はこれを聞いた時、成る程と思いました。昔から触っていて、それぞれのサービスができた時に一つづつ覚えてきた人間には、この悩みは起きにくいなぁという点です。これから利用するユーザに対して、何らかの配慮が必要なのでしょう。

Amazon Web Services クラウドネイティブ・アプリケーション開発技法の場合



 Amazon Web Services クラウドネイティブ・アプリケーション開発技法は、EC2を一切利用せずにアプリケーションのバックエンド・サービスを構築する方法の説明をしています。実はEC2だけではなく、VPCも一切使っていません。
 理由としては、2つあります。1つ目は、サービスを素早く使って貰うことにより、VPCの構成に悩むなど挫折してほしく無いためです。(VPCの作成については、前作読んで貰いたいし)そして、2つ目は、実はVPCなくてもちゃんとセキュリティを意識したサービスを作れるからです。

VPC対応とセキュリティ



 日常は、いわゆるエンタープライズと呼ばれるような企業さんと一緒に仕事をしていることもあり、AWSさんにAWSの各種サービスのVPC対応をよろしく頼みますとかお願いしていたりします。一方で、VPCが無いからセキュリティが低いと考えるのは、思考停止だなと思っています。VPCを使う理由としてはアクセス元制限などがありますが、実はVPCを使わずにちゃんと出来るんだぜということを、Amazon Web Services クラウドネイティブ・アプリケーション開発技法に書いているつもりです。

感想



 VPCを使おうが使うまいがクラウドネイティブとは関係ないと思います。一方で、VPCに対応していないサービスはセキュアではないと考えている人もいるのも事実です。個人的にはもっとクラウドの利用が進んでいると、VPCというのが使われなくなってくるのではと考えています。理由としては、EC2やRDSではなくDynamoDBやLambdaというサービスを使っていくとVPCの枠組みに収まらなくなってくるからです。もちろんAWSは、しっかりと各種サービスのVPC対応はしていくでしょう。一方で、ユーザーとしては必ずしも使う必要はないかもしれません。


See Also:
アプリケーションエンジニア向けのAWS本を書きました
Amazon Web Services クラウドネイティブ・アプリケーション開発技法の目次
Amazon Web Services クラウドネイティブ・アプリケーション開発技法のサンプルアプリケーションをGitHubで公開しました
エンジニアよ、越境しよう!!クラウド時代のエンジニア像
『Rubyによるクローラー開発技法』を書きました
『Amazon Web Services パターン別構築・運用ガイド』を書きました

Amazon Web Services クラウドネイティブ・アプリケーション開発技法の電子書籍化とパターン別構築・運用ガイドの増刷決定!!

 書名が長いので何とかして欲しい今日この頃ですが、表題の通りAmazon Web Services クラウドネイティブ・アプリケーション開発技法が電子書籍化しています。また、Amazon Web Services パターン別構築・運用ガイドの増刷も決定しました。著者冥利につきます。ありがとうございます!!

f:id:dkfj:20160423090211p:plain
f:id:dkfj:20160421171418j:plain

Amazon Web Services クラウドネイティブ・アプリケーション開発技法



 一部の間で分厚いを通り越して鈍器のような本と呼ばれている『Amazon Web Services クラウドネイティブ・アプリケーション開発技法』です。ポータビリティが無いので、電子書籍版でないのと良く聞かれていました。私自身も電子化の計画は解らなかったのですが、ほぼ発売日と同時に実現できました。
 しかし、従来の電子化の問題点も引きずっております。画像ベースのPDFのため、サイズが大きい・検索/ハイライトが出来ないといった問題があります。これについては出版社に繰り返し要望していますが、電子書籍の市場がまだまだ小さいのでコストを余り掛けられないというところに起因しています。技術書として使いにくいから普及せず、普及しないからコストを掛けられずという『卵が先か鶏が先か』問題ですね。
 一方で、電子書籍だと増刷時や改訂時にアップデートできるというメリットもあるので、ここのメリットは著者として提供していきたいと思います。

Amazon Web Services パターン別構築・運用ガイド



 1年前に発売した『Amazon Web Services パターン別構築・運用ガイド』ですが、未だに売れ続けています。EC2やVPCなどAWSを扱う為にベーシックな機能を中心に取り扱っています。お陰で生きの長い本になりそうです。クラウドネイティブ・アプリケーション開発技法との相乗効果で、Amazonのクラウドランキングで1位、2位を独占することが出来ました。ありがたい限りです。
f:id:dkfj:20160423085459p:plain

今後の予定



 おかげ様で、複数の執筆依頼がきています。その中にはAWS関係もあるし、全く別のテーマのものもあります。依頼される間が華なので、出来る限り対応していきたいです。でもその前に、一度Kindleダイレクト・パブリッシングに挑戦してみたいですね。



See Also:
アプリケーションエンジニア向けのAWS本を書きました
Amazon Web Services クラウドネイティブ・アプリケーション開発技法の目次
Amazon Web Services クラウドネイティブ・アプリケーション開発技法のサンプルアプリケーションをGitHubで公開しました
エンジニアよ、越境しよう!!クラウド時代のエンジニア像
『Rubyによるクローラー開発技法』を書きました
『Amazon Web Services パターン別構築・運用ガイド』を書きました

実録!!15分で出来るクラウドネイティブなアプリ構築例。コーディングからアプリのデプロイまで

 4/20発売のAmazon Web Services クラウドネイティブ・アプリケーション開発技法は、順調な出だしのようで一安心です。本を出すと気になるのが、Amazon上でのランキングです。全体ランキングで10,000位以内であれば技術書であればかなり売れている方です。そして、発売開始直後は1,000位以内でいてほしいです。そんなこともあって、わりとチョクチョク順位を確認しています。

Amazonのランキングはスマホのブラウザから表示されない



 Amazon内順位の確認ですが、とある問題があります。スマホのブラウザの場合は、表示されないのです。これだけでは伝わらないと思うので、写真を見てください。

まずPCから見たAmazonのページです。
f:id:dkfj:20160422074234p:plain
Amazon 売れ筋ランキングの他に、カテゴリごとの順位がでていますね。

次にモバイルです。
f:id:dkfj:20160422072124j:plain
さっぱり表示されません。

API Gateway + Lambdaで解決する



 以前は、KimonoLabsというスクレイピングサービスで30分に一度順位を取得させていました。しかし、2016年2月に(私の中で)惜しまれつつもサービスが終了してしまいました。まぁなければ作れば良いやということで、API GatewayとLambdaを使ってAmazon上から特定の項目だけを取得するようにしました。構成としては、以下のとおりです。

f:id:dkfj:20160422074905p:plain

 LambdaからNode.jsのモジュールであるcheerio-httpcliを呼び出し、Amazonの商品詳細ページからランキングの部分だけを抜き出しています。順位は、HTML中の要素liのidがSalesRankに含まれています。かなり雑ですが、下記のようなコードで取得できます。

'use strict';
let client = require('cheerio-httpcli');

exports.handler = (event, context, callback) => {
  client.fetch('http://www.amazon.co.jp/dp/4797386312/', { q: 'node.js' }, function (err, $, res) {
    console.log(res.headers);
    console.log($('title').text());
    let list = '';
    let rank = $("li[id=SalesRank]").text();
    console.log(rank);
    callback(null, rank);
  });
};

取得結果は以下のとおりです。
f:id:dkfj:20160422075147j:plain

 余計な要素が多いですが、そこはスクレイピング後の整形でなおせます。これくらい雑なものであれば、慣れていればコードとあわせて15分もあれば作れれます。

感想というか本の宣伝



 今回の本は、このような感じでAPI GatewayとLambda、それ以外にCognitoやDynamoDBといったものを中心に扱っています。ここで紹介した例は非常にシンプルですが、例えば高速に応答したい場合に、予め処理を定期的に動かすにはどうするかや。その結果を保存するにはといった具体的なことを書いています。どういう場合に、どのサービスを使えばよいのか実際のコードと共に実例集みたいな感じにもなっています。
 クラウドネイティブ・アプリケーションというと御大層な感じがしますが、自分が欲しいものをサクッと作れるように、その考え方・作り方の説明書となっています。少しでも興味を持ってもらえればなぁと思います。本屋さんで見かけたら、ぜひ手にとってパラパラめくってください。ちなみにスクレイピングの話は、取り扱っていません。


See Also:
アプリケーションエンジニア向けのAWS本を書きました
Amazon Web Services クラウドネイティブ・アプリケーション開発技法の目次
Amazon Web Services クラウドネイティブ・アプリケーション開発技法のサンプルアプリケーションをGitHubで公開しました
エンジニアよ、越境しよう!!クラウド時代のエンジニア像
『Rubyによるクローラー開発技法』を書きました
『Amazon Web Services パターン別構築・運用ガイド』を書きました