プログラマでありたい

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

コンテナ化とサーバーレス、2つのトレンドに対する雑感

 日本からre:Inventを眺めていた雑感です。速報で2つほど新サービスに対しての感想をまとめていますが、今回は全体的なトレンドに対して今考えている事です。今回は1行じゃないですよ。

サービス展開の方向は、全方位的


 サービスの展開方向としては、去年と変わらないような気がします。他のクラウド(Google, Azure)に対して弱かった部分をきっちりキャッチアップし、伸びている分野(AI・機械学習)のラインナップを増やしていく。そして、サードパーティが提供している機能に対して、一定以上の規模が出てくると(買収 or 自社開発で)サービス化する。いわゆるサードパーティ殺し。
 そんな中で提供されているサービスの作り方/インフラ的な部分を見てみると、コンテナとサーバレス(lambda)を使った物が多いです。AWS自身がコンテナとサーバレスを活用することで、開発を加速しサービスをスケールしやすくしていることが見て取れます。

2015年のWerner VogelsのKeynoteを振り返る


 そんな光景をみていると思い出すのが、2015年のWerner VogelsのKeynoteです。『自由』をテーマにビジネス/エンジニアが何から開放されるのかを語っていました。注目は、その中の一枚のスライドです。

f:id:dkfj:20171203062754p:plain

AWS re:Invent 2015 Keynote | Werner Vogels - YouTube
www.youtube.com

 AWSの中心的な存在である仮想マシン(ec2)に対して、コンテナとfunctions(≒Lambda,サーバレス)を並べています。当時のトレンドとしては、コンテナに対する理解はだいぶ進んでいたものの、functionsに対しては何じゃそれというのが大半でした。そんな情勢なのに、コンテナだけでなくfunctionsについても同列に置くのかと驚いていました。
 次の2枚の写真は、Google Trendsでみる検索数の推移です。検索語については変えていますが、コンテナの方が当時でも優勢です。

f:id:dkfj:20171203063749p:plainf:id:dkfj:20171203064110p:plain

 その後をみていると、特にIoT関連のサービスが顕著なのですが、サービスがLambda連携で作られているモノ/拡張される物が多数出てきています。ユーザーにはfunctionsを使わせるという方向です。で、このコンテナとfunctionsですが、別に対立的な関係になっている訳ではないのです。
 AWSが作ってるLambdaも(Dockerじゃないけど)コンテナをベースに作られています。そして、そのコンテナもEC2などの仮想サーバをベースに提供されています。つまり、個々のトレンドは一足飛びで突然出てきている訳ではなく、連綿と続くサービスの積み重ねの上で提供されているということです。ということで、クラウド・プロバイダという点では、AWS, Google, Azure以外の所の台頭は難しいんでしょうね。例外的には、中国という独自の環境で育ったAlibabaがありますが。

それでは、ユーザーはどうするか?


 じゃぁ今後ユーザーはシステムをどうやって作っていけば良いのでしょうか?何でもサーバーレス・何でもコンテナって考えると、たぶん失敗します。結論的には、月並みな言葉ですが、適材適所で作っていきましょうとなります。
 まずサーバーレスですが、作る上での制約が厳しいです。 API Gateway・Lambdaを始め、AWS側の制約に則って作る必要があります。だってAWSのルールですから。一方で、システム構築/サービス展開する上で、この制約に則って作ることは良いものが出来る可能性は高いです。何故ならば、AWSが今まで作ってきたもののベストプラクティスを元にしているからです。その為、非機能要件のような汎用的に求められるものについては、サーバレスの仕組みにデフォルトで組み込まれています。だからサーバーレスで作れないか検討してみましょう。それが駄目だったら、コンテナか普通の仮想マシンを検討するのが良いです。
 次にコンテナ。これも新規に作るシステムだったら、仮想マシンじゃなくてコンテナから検討した方が良いと思います。一方で、過去のシステムをコンテナ化しようとすると、作った人を恨みたくなるとかいろいろ闇が出てくるので止めた方が良いかもしれないです。逆にこれから作るシステムでコンテナ化できないようなものは、たいていの場合はアーキテクチャなり設計を見直した方がよいです。システムが密結合になり過ぎているということでしょう。
 一方で、システム/サービスの肝となる部分については、サーバーレス・コンテナに縛られずにゼロベースで考えるべきです。プラットフォームの制約のためにサービスの性質を変えるというのは、恐らく間違っている可能性が高いです。

コンテナ化とサーバーレス化が進んだ後の世界


 ついでにコンテナ化とサーバレス化が進んだ後はどうなるのだろうと、ちょっと考えてみましょう。恐らくマルチクラウド化が進むと思います。コンテナ・サーバーレスともシステム/アプリケーションの可搬性を高めます。そうなると、AWSで動かしてたシステムをGoogleやAzureに持っていくことが簡単になります。当然、逆も然りです。
 可搬性が高いのであれば、より有利なクラウドを選ぶようになります。例えば、re:Inventの発表前では、AWSはKubernetesベースのサービスは提供されていませんでした。そこで、コンテナ関係はGoogleのクラウドを利用するという選択肢があり、実際AWSをメインに使っていてコンテナ部分だけGoogleで動かしているという話も結構聞きます。

マルチクラウド化になると複数のクラウドを使えなければいけないのか?


 じゃぁみんなが複数のクラウドを使いこなさないと駄目なのでしょうか。これはNoだと思います。まず、企業としては規模次第です。大規模な会社でシステムも多く多数のエンジニアがいる場合は、適材適所でクラウドを使い分ければよいと思います。一方で少人数のエンジニアチームで複数のクラウドを使いこなすというのは、よっぽどの精鋭チームでしか出来ないと思います。また、個人にフォーカスしてみると全部のクラウドに精通するということは、時間的な制約で恐らく難しいでしょう。複数のクラウドのマスターだよって人は是非手をあげてください。今だと引く手あまたです。
 マルチクラウドの話に戻すと、恐らくデータの集積の基本となるクラウドと、それを元に部分的に複数のクラウドを使っていくという形が増えていくのではないでしょうか。今だとデータをS3に集めて、AI部分のみ別のクラウド使って、またADだけAzure使ってという所は結構あるかもしれません。基本となるクラウドが1つあれば、後は良いとこ取りできるよというのがマルチクラウドだと思います。

まとめ


 毎年、re:Inventで発表されるサービスを見るたびに、この先どこで食っていこうかなと思います。ここ2〜3年は、コンテナ・サーバーレスの知見があれば食っていくことには困らないでしょう。一方で、正味のシステム構築部分自体は小さくなってきます。昔から言われていますが、SIer的なピラミッド構造の産業は難しくなってくるでしょうね。また、発注側の情報システム部門も厳しくなると思います。だって、クラウドに着いて行くのが難しいんだもん。

シリーズ
AWSの新サービス群に対する一行所感
(続)AWSの新サービス群に対する一行所感

Amazon Web Services パターン別構築・運用ガイド  一番大切な知識と技術が身につく

Amazon Web Services パターン別構築・運用ガイド  一番大切な知識と技術が身につく

  • 作者: NRIネットコム株式会社,佐々木拓郎,林晋一郎,小西秀和,佐藤瞬
  • 出版社/メーカー: SBクリエイティブ
  • 発売日: 2015/03/25
  • メディア: Kindle版
  • この商品を含むブログを見る

(続)AWSの新サービス群に対する一行所感

 昨日のAWSの新サービス群に対する一行所感に続き、二回目です。タイトル通り一行じゃないのは、書いてる時の気分の問題です。

AWS Serverless Application Repository


Serverlessアプリケーション版のGithub。SAM形式で作ってたら公開可能。限定公開とか一般公開とか出来る 。とりあえず9割の人が利用者側にまわるサービスかな。

aws.amazon.com

AWS Cloud9


2016年にAWSに買収されたオンラインIDEのCloud9。1年の雌伏の時を経てAWSのサービスとして登場。ペアプロとかも出来る。ちなみにCloud nineというのは、至福という意味

aws.amazon.com

Amazon EC2用スプレッドプレイスメントグループ


 従来のプレイスメントグループに、機能拡張。今までは、ネットワーク的に近くという目的だったが、今度は物理的に別の筐体にという指定。耐障害性があがるが、Multi-AZ構成と性能計算をちゃんとやってればいらないのではという気も。一方で、デフォルトで指定されててもいいかも。

aws.amazon.com

インターリージョンVPCピアリング


 リージョンまたいでのVPCピアリングが可能に。先月発表されたDX Gatewayと併せて、どう使うかよーく考えよう。
※ほぼ執筆完了した本で、企業のネットワーク設計をどうすべきかという話をあーだこーだ書いてて前提が変わったので困ってる

aws.amazon.com

AWS WAFのマネージドルール


WAFの設定をTrend Microのような専門の会社から買うことが出来る仕組み。当然、定義の自動アップデート機能付き。セキュリティ会社的には嬉しいだろうが、AWSへの従属性高まるので手放しでは喜べないだろうなぁ

aws.amazon.com

T2 Unlimited


 バースト特性のあるt2インスタンス。問題は、バースト期間を過ぎると極端に性能が落ち、バーストしている時は例外なく負荷高い時なので、切れると死ぬということ。それをお金で解決するのがT2 Unlimited

aws.amazon.com

API GatewayのVPCサポート


ようやく来たAPI GatewayのVPC対応。今まで何度お客さんに、何でVPC内で使えないのと聞かれたことか。

Amazon API Gateway でプライベート VPC とのエンドポイント統合をサポート

まとめ


 EFSやSQSのFIFOキュー、結局東京リージョンに来なかったね。

シリーズ
AWSの新サービス群に対する一行所感
コンテナ化とサーバーレス、2つのトレンドに対する雑感

Amazon Web Services 業務システム設計・移行ガイド (Informatics&IDEA)

Amazon Web Services 業務システム設計・移行ガイド (Informatics&IDEA)

  • 作者: 佐々木拓郎,林晋一郎,瀬戸島敏宏,宮川亮,金澤圭
  • 出版社/メーカー: SBクリエイティブ
  • 発売日: 2018/01/20
  • メディア: 単行本
  • この商品を含むブログを見る
Amazon Web Services パターン別構築・運用ガイド  一番大切な知識と技術が身につく

Amazon Web Services パターン別構築・運用ガイド  一番大切な知識と技術が身につく

  • 作者: NRIネットコム株式会社,佐々木拓郎,林晋一郎,小西秀和,佐藤瞬
  • 出版社/メーカー: SBクリエイティブ
  • 発売日: 2015/03/25
  • メディア: Kindle版
  • この商品を含むブログを見る

AWSの新サービス群に対する一行所感

 今年もラスベガスで、AWSの最大のイベントre:Invent開催中です。初回のキーノートが終わった所ですが、怒涛のサービス発表で頭が混乱中です。整理のために、サービスに対する感想をつけてみます。間違っているかもしれないので、悪しからず。

AWS AppSync

 モバイル等での複数端末のデータ同期を見据えたソリューション。必要性はすごく解るが、それってCognito Syncでやりたかったことじゃないのかな?認証認可のサービスにデータ同期を加えた筋の悪さを解消に来たのか?

2017/12/3 追記
中の人曰く、次のような役割分担とのこと

AWSの新サービス群に対する一行所感 - プログラマでありたい

ありがたし / Cognito Syncは「一つのIdentityに(≒一人の人間)が持つ」複数端末間での設定値等の同期のためのものだったので、前提と志向が違うのです > AppSync “それってCognito Syncでやりたかったことじゃないのかな?”

2017/12/03 12:21
b.hatena.ne.jp


aws.amazon.com

Amazon GuardDuty

 初見の印象は、TrendMicroを殺しに来るサービス。一方で、TrendMicroの方もLauch Partnerとして、Amazon GuardDuty and Deep Securityを出してきている。庇を貸して母屋を取らないようにギリギリのところで勝負している印象。

aws.amazon.com

Amazon EC2 Bare Metal

 生のハードウェアを貸しますよという昔のSoftLayerのようなサービス。目的は2つあって、全ての仮想化サーバーをAWSで取り込めるようにするのと、ガチGPU勢とかハードウェアリソースを100%使いたい人に対応だと思う。これ普及したら、なんちゃってプライベートクラウドはなくなるだろうね。

aws.amazon.com

Amazon MQ

 Apache Active MQのPaaS版。既存のMQ入れている所に対して、そのまま移行できますよというサービス。IBMとかを殺しにいっているのかな。SQSを既に使っている人は、そのままSQSで良いでしょう。ところで、FIFOキューは日本に来ないの?

aws.amazon.com

AWS Fargate

 仮想サーバじゃなくてコンテナを直接起動するサービス。もう世の中、コンテナだよね。中の人曰く、イベント・ドリブン的なサービスは、Lambda。ロングランなバッチなどにはFargate。

aws.amazon.com

Amazon Aurora Serverless

 もうちょっと名前の付け方考えた方がよいのではというのが、Aurora Serverless。Lambda等のサーバレスアーキテクチャと親和性が高いAuroraという訳ではない。単純に個々のインスタンスを意識せず良い塩梅にコントロールしてくれるというサービス。PaaSのAuroraが、SaaSのAuroraになったようなイメージ。

aws.amazon.com

Amazon Neptune

 フルマネージドなグラフDBサービス。これ、裏でAuroraの技術使っているのではという気もする。いずれにせよ、NoSQLも自前でインストールして使う時代ではなくなったのだろう。

aws.amazon.com

Amazon DynamoDBにGlobal TablesとOn-Demand Backup追加

 Global Tablesは、AzureのCosmoDB、Google Spannerを意識した機能かな。バックアップ/リストアは、ようやく来たのかという感じ

aws.amazon.com

Amazon Elastic Container Service for Kubernetes

 予想通りECSのKubernetes対応が発表。去年のがっかり感が、ようやく解消。略称がEKSというところに、Amazonのプライドと苦悩が垣間見れる。

aws.amazon.com

S3 Select と Glacier Select

 Simple Storage Serviceという名前に関わらず、恐ろしく多機能になっているS3。Select文でオブジェクトの一部のデータが抽出が可能に。Athenaとかの開発の副産物でしょうな。

aws.amazon.com

Amazon Rekognition Video

 映像の認識処理のサービス。ぜったいDMMのAPIとつないでみる奴でてくるで

aws.amazon.com

Amazon SageMaker

 機械学習のライフサイクルをサポートするサービス。これもサードパーティー殺しだな

aws.amazon.com

Amazon Transcribe

 音声⇒テキスト変換。初回Launchは、英語・スペイン語のみ。きっとすぐに、日本語に対応してくれるでしょう。

aws.amazon.com

Amazon Kinesis Video Streams

 大量のセンサーデータをKinesisが扱うように、ビデオ画像もKinesisで扱えるようになった。先述のRekognition Videoのようなものと組み合わせて、防犯カメラからの映像をリアルタイムで異常検知というようなことができるようになるんでしょうね。

aws.amazon.com

Amazon Translate

 リアルタイム翻訳サービス。APIが提供されるだろうからプロダクトに組み込みやすいだろうが、精度の点でGoogleに勝てるのだろうか?

aws.amazon.com

IoTサービス群

 怒涛のIoT関係サービスのリリース。これで、ほぼほぼ出揃った?

 AWS IoT Device Defender IoT版のDeepSecurityみたいな感じ?

aws.amazon.com

 AWS IoT Device Management IoTの個々の機器の管理。やっぱり必要だよね

aws.amazon.com

 AWS IoT Analytics IoTの分析サービス。AWSは分析サービスをいろいろ出してるけど、どれもイマイチ感は拭えない。。。

aws.amazon.com

 Amazon FreeRTOS IoT用のOSまで作っちゃいました。

aws.amazon.com

AWS Systems Manager

 EC2 System Managerを更にラップしたようなサービス。複数のEC2やRDS,S3をグルーピングしてくれる。もうちょっと拡張してIAMの権限管理とかもできれば、本番・開発環境のために複数アカウントとかする必要なくなるのだけどなぁ

aws.amazon.com

Amazon Time Sync Service

 とどのつまりが、NTPサービス。やっと出してくれたのかという反面、なんで今までなかったのか。

aws.amazon.com

Amazon Comprehend

 自然言語処理。Mecab以来目立って進化していないような気がするので、何気に嬉しいし使い所が沢山ありそう。自然言語処理ってなんぞやと言う人は、文章中から特定のキーワードを引っこ抜くとか単語単位に分解するサービス程度に認識してればO.K.

aws.amazon.com

まとめ

 まとめきれません。

続き
(続)AWSの新サービス群に対する一行所感
コンテナ化とサーバーレス、2つのトレンドに対する雑感


Amazon Web Services 業務システム設計・移行ガイド (Informatics&IDEA)

Amazon Web Services 業務システム設計・移行ガイド (Informatics&IDEA)

  • 作者: 佐々木拓郎,林晋一郎,瀬戸島敏宏,宮川亮,金澤圭
  • 出版社/メーカー: SBクリエイティブ
  • 発売日: 2018/01/20
  • メディア: 単行本
  • この商品を含むブログを見る
Amazon Web Services パターン別構築・運用ガイド  一番大切な知識と技術が身につく

Amazon Web Services パターン別構築・運用ガイド  一番大切な知識と技術が身につく

  • 作者: NRIネットコム株式会社,佐々木拓郎,林晋一郎,小西秀和,佐藤瞬
  • 出版社/メーカー: SBクリエイティブ
  • 発売日: 2015/03/25
  • メディア: Kindle版
  • この商品を含むブログを見る

公文が出しているNEW スタディ将棋のUIが素晴らしい

 息子が幼稚園の年長になってきて、いろいろな事に興味を持つようになってきました。そして知人に公文が出している将棋盤が良いよと聞いたので、試しに買って将棋を教えてみました。これが中々素晴らしいので紹介します。

NEW スタディ将棋 (リニューアル)

NEW スタディ将棋 (リニューアル)

NEW スタディ将棋



 NEW スタディ将棋は、名前の通り将棋の動かし方を学べるようになっています。その最大の特徴は駒を見れば解るように、駒の動けるところが、一つ一つの駒に書いてある点です。幼稚園児でも1〜2回教えると、ほぼ駒の動きが解るようになっています。実際、並べて見たところと、成った所は次のような感じです。
f:id:dkfj:20170620011657j:plain
f:id:dkfj:20170620011749j:plain

優れたデザイン



 NEW スタディ将棋を使ってみて、優れたデザインというのはこういうものだなと実感しました。従来の子供向きの将棋盤だと、駒の動かし方をマンガ形式の説明書で解説するといったものだと思います。それを駒自身に書くという大胆な手法で、説明書を不要にしている点が素晴らしいです。システムを作る身としては、このデザイン・UIの考え方は大切にしていきたいです。
 ちなみに駒や盤自体の素材は、それほど良いものではありません。盤は合板ですし、駒も何となくささくれている感じです。しかし、小さい子が使うと考えれば充分でしょう。合板なので軽くて良いです。

感想というか悩みどころ



 ということで、息子がすっかり将棋好きになりました。一度始めると何局もやれと言ってきて、中々時間の確保が大変です。あと、私が勝つと怒るので、どうやって息子に勝たせられるように強くするか悩みどころです。どうしたら良いのでしょうね?

NEW スタディ将棋 (リニューアル)

NEW スタディ将棋 (リニューアル)

触って覚えるサーバレス入門!!『サーバーレス シングルページ アプリケーション』

 監訳者の@yoshidashingoさんにサーバーレス シングルページ アプリケーションを頂きました。ありがとうございます。

f:id:dkfj:20170620015140j:plain

 

本書の内容



 本書の内容としては、名前の通りサーバーレスでシングルページアプリケーションを構築する方法がテーマとなっています。ただどちらかと言うと、シングルページ アプリケーションはおまけで、サーバーレスのAPIを作ることがメインとなっています。機能説明だけでなく実際に手を動かしながら覚えていくというスタイルで、その為に200ページ弱と薄めの本となっています。サクッと読めて、それでも一通りの事はカバーしているという中々よい構成です。

Cognito,DynamoDB,Lambda+API Gateway



 サーバーレスの中心として、本書ではCognito,DynamoDB,Lambda+API Gatewayの4つを中心に扱っています。基本的な使い方からチップス的なものまで扱っています。それぞれ20〜30ページくらいで説明しているので、分量的に多くなく適量なのではないでしょうか。
 例えばDynamoDBの章では、DynamoDBの歴史から強い整合性と結果整合性、インデックスの話など基本的な機能の説明から、DynamoDBへのアクセス許可に際してのIAMのポリシーの設定など具体的なことまで記述されています。この中でConditionの項目で置換変数を使ってCognito IDを使って自分のデータのみしか参照/更新できないような制限など、一般的に頭を悩ます部分についてもサラッと答えを書いているのが好感です。

サーバーレスのセキュリティ&スケールアップ



 この本で特に良いなぁと思った所が、7章の『サーバーレスのセキュリティ』と8章の『スケールアップする』です。サーバーレスの構築事例や運用実績は、まだまだ世の中に出てきているものが少ないです。そうなると構築する際に困るのが、どのようなセキュリティ施策・運用の想定をすればよいか解らないということです。そういった意味で、独立した章としてそれぞれを扱っているのは素晴らしいです。
 セキュリティについては、サーバーレスの施策というよりAWSの基本的な設定であったりJavaScript側の施策であったりと、まだまだ書き足すところは多いかもしれません。それでも、クエリインジェクション・クロスサイトリクエストフォージェリ・DDoSと代表的な攻撃に対する対処方法が書かれています。
 スケールアップの所でフフフとなったのが、S3のアクセス集計。S3のログを元にシェル芸を駆使していました。『S3Webトラフィックを解析する』というタイトル見て、Google Analytics使えという内容かと思ったのですがAWSオンリーで行くという心意気を感じました。ちなみにこんな感じです。

$ aws --profile admin s3 sync s3:learnjs-logging.benrady.com/ logs
$ cat logs/* | cut -d ' ' -f 13 | sort | uniq -c

 どうせならawkコマンドをだして紛らわしくしたら良いのではと思いながら読んでいたのですが、後ろの方でしっかり出てきました。

$ cat logs/* | awk '{ print $3 }' | gr ':' ' ' | \
  awk '{ print $2 ":" $3}" | sort | uniq -c

 シェル芸好きとしては、満足です。ただ現実的な運用では、Google Analyticsをお勧めします。
それ以外にも、バージョニングを利用したキャッシュコントロールなどがあり一読をお勧めします。

感想



 非常に読みやすくて、サーバーレスとは何ぞやと知りたい人にはお勧めの一冊です。が、個人的には非常に悔しい一冊です。実は、この本の原書の発売が2016年6月14日です。私も『Amazon Web Services クラウドネイティブ・アプリケーション開発技法』という本を出しており、テーマも発売時期もほぼ同じでした。ただ主題をシングルページ アプリケーションではなくモバイルアプリにしました。書名もサーバーレスかクラウドネイティブか悩んだ末に、クラウドネイティブにしました。後はあれもこれもと欲張り、KinesisやMachine Learning, AWS IoT, Mobile Hubなど詰め込みすぎました。結果700ページ超の分厚さになり、知る人ぞ知るというマニア向けの本となってしまいました。この本を読んで、改めて対象を絞り込むことが大切だなぁと実感しました。良い本です。

サーバーレスシングルページアプリケーション ―S3、AWS Lambda、API Gateway、DynamoDB、Cognitoで構築するスケーラブルなWebサービス

サーバーレスシングルページアプリケーション ―S3、AWS Lambda、API Gateway、DynamoDB、Cognitoで構築するスケーラブルなWebサービス


以下、目次です。

目次


本書への推薦の言葉
監訳者まえがき
はじめに
目次

1章 シンプルにはじめる
1.1 サーバーレスWebアプリケーション
1.2 ワークスペースを使う
1.3 Amazon S3にデプロイする
1.4 はじめてのデプロイ

2章 ハッシュイベントによるビューのルーティング
2.1 テストしやすいルータを設計する
2.2 ルータ関数
2.3 ルートを追加する
2.4 ビューパラメータを追加する
2.5 アプリケーションをロードする
2.6 再びデプロイする

3章 シングルページアプリケーションに必要なもの
3.1 ビューを作成する
3.2 データモデルを定義する
3.3 ユーザー入力を処理する
3.4 アプリケーションシェルを作成する
3.5 カスタムイベントを使う
3.6 再びデプロイする

4章 Amazon CognitoによるIdentity as a Service
4.1 外部のアイデンティティプロバイダに接続する
4.2 アイデンティティプールを作成する
4.3 Googleアイデンティティを取得する
4.4 AWS認証情報をリクエストする
4.5 プロファイルビューを作成する
4.6 再びデプロイする

5章 DynamoDBにデータを格納する
5.1 DynamoDBと連携する
5.2 テーブルを作成する
5.3 DynamoDBへのアクセス許可
5.4 ドキュメントを保存する
5.5 ドキュメントを取得する
5.6 データアクセスと検証
5.7 再びデプロイする

6章 Lambdaを使って(マイクロ)サービスを作る
6.1 AWS Lambdaを理解する
6.2 まずデプロイする
6.3 Lambda関数を書く
6.4 Lambda関数を呼び出す
6.5 Amazon API Gatewayを使う
6.6 再びデプロイする

7章 サーバーレスのセキュリティ
7.1 AWSアカウントをセキュアにする
7.2 クエリインジェクション攻撃
7.3 クロスサイトスクリプティング攻撃
7.4 クロスサイトリクエストフォージェリ
7.5 盗聴とトランスポート層のセキュリティ
7.6 サービス拒否(DoS)攻撃
7.7 再びデプロイする

8章 スケールアップする
8.1 Webサービスを監視する
8.2 S3Webトラフィックを解析する
8.3 成長に合わせて最適化する
8.4 クラウドのコスト
8.5 再びデプロイする(何度も、何度も)

付録A Node.jsのインストール
A.1 Node.jsランタイムをインストールする
A.2 複数のNode.jsバージョンを管理する

付録B ドメイン名を割り当てる

参考文献

不確実性コーンの話

 アジャイル界隈では割と知られているのですが、見積もりが何故ずれるかという説明の1つに不確実性コーンというものがあります。ざっくり説明するとプロジェクトの初期段階では不確定要素が多いので見積もりには4倍くらいの誤差があり、プロジェクトの進行とともに不確実な部分が少なくなってきて誤差は収束に向かうという話です。

f:id:dkfj:20170518115300p:plain

引用:プロジェクトマネジャーのための「プロセス設計術」 - プロジェクトの本質とはなにか:ITpro


 この不確実性コーンですが、個人的には次のように解釈しています。

  • プロジェクト開始時には、全ての情報が揃うことはないので見積もりには誤差が生じる
  • 全ての情報を集めてからプロジェクトを始めるのは現実的ではない。
  • ブレを小さくするには、出来るだけ対象となる範囲を小さくする。(タスクを細かい単位に分解する)

 個々の仕事の処理能力が高いのに、何故か仕事が遅い人というのがたまにいます。そんな人を見てると、自分が持っているタスク全部の見積もりを最初にやってから、個々の仕事に取り掛かろうとする傾向が多いように思えます。不確実性が多い段階の見積もりはブレが大きいとともに、見積もり自体も大変で労力が必要です。
 それを回避するにはどうしたら良いのか?目の前の優先度の高い1つのタスクだけに向き合えばよいのです。優先度が高いということは、基本的には不確実が少ないです。悩む余地がないので、実質的な仕事をしている時間が増えるのでサクサクと進みます。結局仕事の早い遅いって、実質的な作業にどれだけ時間をさいているかというところなのではないでしょうか?

See Also:
仕事を分解する。

アジャイルな見積りと計画づくり ?価値あるソフトウェアを育てる概念と技法?

アジャイルな見積りと計画づくり ?価値あるソフトウェアを育てる概念と技法?

Amazon Product Advertising APIが、IAMユーザーに対応していた

 Amazonの商品リンク等を生成するAmazon Product Advertising APIというサービスがあります。これは、今でいうAWS(Amazon Web Services)が出てる前は、Amazon Web Serviceという名前でした。このサービスはAWSが出る前から存在するということで、IAMユーザーを利用して最小限の権限を付与して利用するという事が出来ませんでした。何とルートアカウントのアクセスキーとシークレットアクセスキーを利用して、APIを操作するという男前仕様です。と言っても、広告のAPIを操作するだけなので、基本的には問題は少なかったです。

 そんな中で、AWSが出てきてAmazon Product Advertising APIのアカウントがAmazon Web Servicesに統合されたことにより問題が顕在化してきました。AWSはIAMが出てきて、ルートアカウントの利用が非推奨なのに、Product Advertising APIの方は依然としてルートアカウントでしか利用できないという問題です。ずっと何とかならんのかなぁと思っていたのですが、いつの間にか改善されているのを発見しました。

IAMユーザーで、Amazon Product Advertising APIを利用する


Becoming a Product Advertising API Developerを見ていると、下記の通りProductAdvertisingAPIの権限を付与することでAmazon Product Advertising APIが利用できるとあります。注意点としては、AWSのコンソールから、IAMのPolicy Generatorを見ても、ProductAdvertisingAPIの権限は出てきません。カスタムポリシーで作る必要があります。Product Advertising APIのIAM対応について幾つかのブログで紹介されていましたが、どれもAdministrator権限を付与しろとありました。それだと、限りなく意味がないので止めましょう。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "ProductAdvertisingAPI:*",
            "Resource": "*"
        }
    ]
}


docs.aws.amazon.com

 さて、いつからIAMユーザに対応したのでしょうか?Internet Archiveを見る限り、2016年末のアーカイブでは対応していなかった模様なので、2017年からの対応のようです。AWSのニュースを見ていても、特にアナウンスは無かったとは思います。扱いが小さいですね。

Node.jsでProduct Advertising APIを呼び出すサンプル



 それでは、このIAMユーザを利用した実際に呼び出せるのか試してみましょう。Node.jsでは、apacというProduct Advertising APIを呼び出すクライアントライブラリがあります。簡単なので、これで試してみましょう。サンプルの部分に、作成したIAMユーザのKeyを埋め込めばそのまま使えます。ただキーをコードに埋め込むのは危険なので、環境変数等を利用しましょう。

const {OperationHelper} = require('apac');

const opHelper = new OperationHelper({
    endPoint:   'webservices.amazon.co.jp',
    awsId:     process.env.AFFILIATE_KEY,
    awsSecret: process.env.AFFILIATE_SECRET,
    assocId:   'your associate id'
});

opHelper.execute('ItemSearch', {
  'SearchIndex': 'Books',
  'Keywords': 'harry potter',
  'ResponseGroup': 'ItemAttributes,Offers'
}).then((response) => {
    console.log("Results object: ", response.result);
    console.log("Raw response body: ", response.responseBody);
}).catch((err) => {
    console.error("Something went wrong! ", err);
});

 ちなみに、このProduct Advertising APIは利用制限が厳しく、デフォルトでは1秒に1回に制限されています。APIで作成したリンクからの売上が上がると、レートが緩和されるという仕様です。
Changes to request limits - Product Advertising API

 レートを超えると下記のようにエラーが出るのでご注意を

Results object:  { ItemSearchErrorResponse: 
   { '$': { xmlns: 'http://ecs.amazonaws.com/doc/2013-08-01/' },
     Error: 
      { Code: 'RequestThrottled',
        Message: 'AWS Access Key ID: AKIXXXXXXXXXXXXXXXXX. You are submitting requests too quickly. Please retry your requests at a slower rate.' },
     RequestId: 'f07ba5e6-e458-40ee-a693-6a2295cf8550' } }
Raw response body:  
<?xml version="1.0"?>
<ItemSearchErrorResponse xmlns="http://ecs.amazonaws.com/doc/2013-08-01/">
  <Error>
    <Code>RequestThrottled</Code>
    <Message>AWS Access Key ID: AKIXXXXXXXXXXXXXXXXX. You are submitting requests too quickly. Please retry your requests at a slower rate.</Message>
  </Error>
  <RequestId>f07ba5e6-e458-40ee-a693-6a2295cf8550</RequestId>
</ItemSearchErrorResponse>

感想



 やっとまっとうになったのだから、もう少し周知した方が良いのではないでしょうか?誰にも知られずヒッソリとなので、Admin権限を与えよといった間違った情報が出回るようになるのです。