2016-05-05

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

Amazon Web Services クラウドネイティブ・アプリケーション開発技法一番大切な知識と技術が身につく (Informatics&IDEA)

posted with ヨメレバ

NRIネットコム株式会社,佐々木拓郎,佐藤瞬,石川修,高柳怜士,佐藤雄也,岸本勇貴 SBクリエイティブ 2016-04-20

Amazon

Kindle

楽天ブックス

2016-04-27

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

Amazon Web Services クラウドネイティブ・アプリケーション開発技法一番大切な知識と技術が身につく (Informatics&IDEA)

posted with ヨメレバ

NRIネットコム株式会社,佐々木拓郎,佐藤瞬,石川修,高柳怜士,佐藤雄也,岸本勇貴 SBクリエイティブ 2016-04-20

Amazon

Kindle

楽天ブックス

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

posted with ヨメレバ

NRIネットコム株式会社,佐々木拓郎,林晋一郎,小西秀和,佐藤瞬 SBクリエイティブ 2015-03-25

Amazon

Kindle

楽天ブックス

2016-04-26

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に頼らないシステムの構築方法を紹介しています。ぜひ御覧ください。

Amazon Web Services パターン別構築・運用ガイド改訂第2版

作者:NRIネットコム株式会社,佐々木拓郎,林晋一郎,小西秀和,佐藤瞬
発売日: 2018/03/23
メディア: Kindle版

Amazon Web Services 業務システム設計・移行ガイド　一番大切な知識と技術が身につく

作者:佐々木拓郎,林晋一郎,瀬戸島敏宏,宮川亮,金澤圭
発売日: 2018/01/20
メディア: Kindle版

2016-04-25

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対応はしていくでしょう。一方で、ユーザーとしては必ずしも使う必要はないかもしれません。

Amazon Web Services クラウドネイティブ・アプリケーション開発技法一番大切な知識と技術が身につく (Informatics&IDEA)

posted with ヨメレバ

NRIネットコム株式会社,佐々木拓郎,佐藤瞬,石川修,高柳怜士,佐藤雄也,岸本勇貴 SBクリエイティブ 2016-04-20

Amazon

Kindle

楽天ブックス

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

posted with ヨメレバ

NRIネットコム株式会社,佐々木拓郎,林晋一郎,小西秀和,佐藤瞬 SBクリエイティブ 2015-03-25

Amazon

Kindle

楽天ブックス

2016-04-23

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ダイレクト・パブリッシングに挑戦してみたいですね。

Amazon Web Services クラウドネイティブ・アプリケーション開発技法一番大切な知識と技術が身につく (Informatics&IDEA)

posted with ヨメレバ

NRIネットコム株式会社,佐々木拓郎,佐藤瞬,石川修,高柳怜士,佐藤雄也,岸本勇貴 SBクリエイティブ 2016-04-20

Amazon

Kindle

楽天ブックス

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

posted with ヨメレバ

NRIネットコム株式会社,佐々木拓郎,林晋一郎,小西秀和,佐藤瞬 SBクリエイティブ 2015-03-25

Amazon

Kindle

楽天ブックス

2016-04-22

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

Amazon Web Services クラウドネイティブ・アプリケーション開発技法一番大切な知識と技術が身につく (Informatics&IDEA)

posted with ヨメレバ

NRIネットコム株式会社,佐々木拓郎,佐藤瞬,石川修,高柳怜士,佐藤雄也,岸本勇貴 SBクリエイティブ 2016-04-20

Amazon

Kindle

楽天ブックス

2016-04-21

エンジニアよ、越境しよう！！クラウド時代のエンジニア像

　Amazon Web Services クラウドネイティブ・アプリケーション開発技法のAppendixとして、「クラウドとエンジニア」をテーマに、クラウド時代のエンジニアのあり方について少し書きました。その趣旨としては、次のようなものです。

従来は、アプリケーション・エンジニアとインフラ・エンジニアという役割で分業することが多かったです。しかし、API GatewayやLambdaのような新しいサービスが出てくる現状で、果たしてそれを扱うのは誰なのだという問題がでてきます。

　図示化すると、次のような感じですね。
f:id:dkfj:20160421080159j:plain

アーキテクチャが変われば、エンジニアの役割も変わる

　今、Webの世界で一般的に見られるアーキテクチャはIntel LinuxサーバやWindowsサーバが普及してからのものです。せいぜい20年位の歴史だと思います。その前は、ホストを中心としたC/Sシステムなどが中心だったのでしょう。つまりプラットフォームが変われば、アーキテクチャも変わります。そして、アーキテクチャが変われば、エンジニアの役割も変わります。
　実は、今回アプリケーションをメインのターゲットにAWS本を書こうとしたのは、上記のモヤモヤっとした考えを文章化しようとしたのがキッカケです。社内のエンジニアとよく話しているのですが、インフラエンジニアがAWSのサービス群を使いこなすことによりアプリエンジニア抜きでソリューションを作ることも出来るし、アプリエンジニアがインフラ構築なしにシステムを作ることも出来るようになってきています。そうなると、両者の線引の意味があるのかとなります。
　もちろん高度に専門的なところは分業する必要があります。技術の細分化が進み、一人の人間が全てを把握するのは不可能に近くなっています。それでも、自分にインフラ・エンジニアやアプリケーション・エンジニアとラベルを貼るのをやめて、まずはいろいろやってみるのが良いのでしょうか？今回の本は、そのキッカケの一つになれるよう目指しています。実際、著者陣も執筆を機に、また一段と変わってきています。エンジニアの皆さん。越境しましょう！！

蛇足

　Amazon Web Services クラウドネイティブ・アプリケーション開発技法のAppendixに上記のようなことを書いています。ブログの会社として有名で、Developers.IOを運営するクラスメソッドさんの中の人がそれを読んで、次のような言葉を頂きました。

ちなみに付録前半を担当されたのはどなたでしょうか？うちのブログのポエム枠投稿してもらえませんかね？w

　本当に、ありがとうございますｗ立派なポエマー目指します。

Amazon Web Services クラウドネイティブ・アプリケーション開発技法一番大切な知識と技術が身につく (Informatics&IDEA)

posted with ヨメレバ

NRIネットコム株式会社,佐々木拓郎,佐藤瞬,石川修,高柳怜士,佐藤雄也,岸本勇貴 SBクリエイティブ 2016-04-20

Amazon

Kindle

楽天ブックス

プログラマでありたい

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

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

Kindle版のメリット

Kindle版の注意点

その他

Amazon AuroraとMariaDB Connector/Jの話

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

MariaDB版Connector/Jの接続方法

MariaDB版Connector/Jの可能性

まとめ

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

s3fs

Storage Gateway

EMRFS（Elastic MapReduce FileSystem）

EFS（Elastic File System）

まとめ

VPCとクラウドネイティブ

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

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

VPC対応とセキュリティ

感想

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

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

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

今後の予定

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

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

API Gateway + Lambdaで解決する

感想というか本の宣伝

エンジニアよ、越境しよう！！クラウド時代のエンジニア像

アーキテクチャが変われば、エンジニアの役割も変わる

蛇足