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

プログラマでありたい

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

AWSとシステムの認証認可を考える

 原稿執筆が追い込みの為に、すっかりとブログから遠ざかっていました@dkfjです。最近、モバイルアプリについて考えることが多いのですが、その中のテーマの1つがシステムの認証認可です。先日、JAWSUGのアーキテクチャ支部で、それをテーマに議論してきたので今時点の課題意識を整理しておきます。

当日の資料



www.slideshare.net

説明が何も書いていないので、これだけ見てもさっぱり解らないと思います。順を追って、説明します。

認証と認可

 まず認証と認可の違いです。認証は本人性の確認であり、認可はリソースに対する利用権限の付与です。多くのシステムでは、認証と同時に認可を行いますが、本質的には別々の機能ですよねという話です。もちろん、1つのシステムの中で同時に実現することの問題もありません。
f:id:dkfj:20160203074335p:plain

Cognitoを利用した認証と認可

 AWSには、認証と認可の部分を簡単にできるサービスとしてCognitoがあります。認証プロバイダとしては、FacebookやTwitterなど外部の認証局を利用できます。OpenID Connectベースの独自の認証局を立てることや、DynamoDBを利用することも出来ます。Cognitoの特徴としては、認証/未認証それぞれに権限を与えることができることです。未認証ユーザには参照権限、認証ユーザには書き込み権限も与えるといったユースケースが考えられますね。

f:id:dkfj:20160203075819p:plain

Cognitoを利用した認証と認可その2

 Cognitoのそれぞれの役割を分割して説明しています。一時的な利用権限の付与が肝となります。また、IAMの設定で、どのリソースを利用可能かを制限できます。
f:id:dkfj:20160203075834p:plain

AWSの認可とアプリケーションが必要とする認可

 このページが、今回の一番のテーマです。AWSの認可とアプリケーションが必要とする認可は違うよねと言うことです。Cognito等で、DynamoDBに対する参照権限を与えたとすると、気を付けないとその認可の範囲が広くなりがちです。例えば、ユーザーデータをDynamoDBに入れていたとしたら、ユーザに与えてよい権限としては、自分のデータに関する部分です。特に2-Tier構成の場合、アプリ側でデータの絞込をするので特に注意が必要です。
f:id:dkfj:20160203075847p:plain

 ちなみにユーザーデータに絞っていえば、CognitoにはCognito Syncという機能があります。そちらの方に格納するのも1つの解です。ただし、イメージ的にはユーザーごとにSQLiteのローカルデータベースを持つようなイメージなので、システムの管理側でユーザーデータをコントロールするといった場合には使えません。

認可のコントロール例

 認可のコントロール例の1つ目としては、その辺りの処理をLambdaにさせたら良いですよねというパターンです。図では、API Gatewayを介していますが、API Gatewayなしで直接Lambdaの2-Tierでも問題ありません。

f:id:dkfj:20160203075905p:plain

認可のコントロール例 その2

 二つ目は、API Gatewayの利用自体も認証済みのユーザに絞るという方法もあるという例です。APIの利用ユーザの認証代わりにAPIキーを使おうとする場合もあります。APIキーは、認証代わりに使っては駄目です。例えばモバイルの場合、APIキーをアプリに埋め込んで配布することになるので、アプリモジュールからAPIキーは抽出可能です。ということで、ちゃんとやる場合はCognito使うのが良いですよ。

f:id:dkfj:20160203075916p:plain

認可のコントロール例 その3

 最後の例としては、Lambda側でCognitoを利用する例です。ここの例では、Cognitoを使っていますが、IAMとAssumeRoleを組み合わせることで、より細かい制御もできます。またIAM Roleの制限数より多いIAM Userを使うということも考えられます。それ以外にも、AWSと離れて、LambdaがADやLDAPなどのユーザストアと会話をすれば色々なことが出来るよねと話していました。

f:id:dkfj:20160203075924p:plain

 ここでIAMを使うとAWSの制限がシステムの制限になってしまうので、個人的には避けたいなと思っています。ケースバイケースですが。

現時点での課題



 認証と認可については、考えれば考える程に奥が深いです。共通のデータを見る場合は、シンプルな認可で充分です。機微な情報の場合は、もう少し厳密にコントロールする必要があります。ただ、あまり細かいことをしようとすると、そもそもLambdaではなく既存の認証フレームワークを使うほうが楽だよねとなります。今後、そういった部分に対応するAWSのサービスや、サードパーティ製のフレームワークが出てくるのではないかなと他力本願で考えています。

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

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

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

数字でみるTV広告と動画配信市場

 先日、ふと気になって日本のTV局の広告収入と動画配信の市場規模を調べてみました。

2014年度の主要局の広告収入



 まずTV局の広告収入です。4大キー局と日本のTV局全体の広告収入を示しています。広告収入のみで、不動産やコンテンツ販売の部分は除いています。(TV局全体は、怪しいけど)

局名 広告収入
日本テレビ 2,385億
フジテレビ 2,312億
テレビ朝日 1,905億
TBS 1,689億
TV全体 1兆9,564億円

f:id:dkfj:20151229081001p:plain

http://www.ntvhd.co.jp/ir/library/presentation/booklet/pdf/2014_4q.pdf
http://contents.xj-storage.jp/xcontents/46760/f47c1a4e/6dfa/4480/a081/7c3d36651de5/140120150519483175.pdf
http://www.tv-asahihd.co.jp/contents/ir_setex/data/2015/20150513.pdf
http://www.tbsholdings.co.jp/pdf/setsumei/setumei201505_2.pdf
http://www.dentsu.co.jp/news/release/pdf-cms/2015019-0224.pdf

各社によって、テレビ広告収入の定義が微妙に違うような気がしますが、まずは参考値として

日本の動画配信サービスの市場規模



 動画配信サービスには、1本あたり幾らのペイパービュー方式と月額固定で見放題のものがあります。有料動画配信の2015年度末予想としては、960万人との数値があります。そのうち月額固定は、590万人とのことです。

2015年 有料動画配信サービス利用動向に関する調査 | ICT総研|市場調査・マーケティングカンパニー

 月額固定のもののみ対象で、月1,000円と仮定すると市場規模は年間で700億円くらいになります。広告収入としては、まだまだ市場の規模としては小さいですね。

 ちなみに海外ではどうなのでしょうか?世界最大の動画配信サービスであるNetflixの場合、米国内加入者総数が4230万人。世界全体では6560万人とのことです。米国内で仮に1,000円とした場合、5,000億円となります。日本とは見えている風景が全然違っていますね。

感想



 この数字が気になったキッカケとしては、最近動画配信サービスを利用する機会が急に増えたことです。また、自分のまわりでも利用者が増えてきています。もっと普及してくるとお金の流れ方が変わるの、またそれはどのタイミングかと気になりました。
 日本の場合、電通・博報堂が広告費を集めてTV局が制作し、視聴者は無料で番組(とCM)を見るという構造でした。一方で米国の場合は、もともとTVはケーブルTVによる有料放送が中心でした。その辺りどう変化していくのか考えていきたいと思います。

Fire TV Stick

Fire TV Stick

See Also
Apple TVを中心としたホームシアター・オーディオ環境の一例
Apple TVでNAS上の動画・音楽を再生する方法
AirPlayを使って、AppleTV+AVアンプでホームオーディオ・システムを構築する話
Hulu(フールー)の契約したった。或いはAppleTVとの連携について

2016年の注目技術

 昨年に引き続き、今年の注目技術を考えてみます。業界の展望というより、個人的に力を入れる予定のところです。まずは昨年の振り返りです。

2015年に注目していた技術



 こちらに書いている通り、2015年はクラウドネイティブが加速するということで、その役割を担うであろうLambdaやCognitoあたりを注目していました。またそれが最初にスタンダードになるのがモバイルということで、その辺りを学習していきました。また一部、AWS本で紹介するなど取り入れています。2015年はAPI Gatewayが登場したこともあり、クラウドネイティブ化は更に進んでいると思います。

2016年の注目技術



 それでは2016年はどうでしょう?もちろんクラウドネイティブ化は、どんどん進んでいくでしょう。AWSの場合、その肝となるサービスはLambdaやAPI Gateway,DynamoDBなどですが、それらのサービスをみていると(ちょっと違うものもありますが)料金体系はリクエスト単位に近いです。またサービス自体が、イベント・ドリブン的なものが増えているように思えます。マイクロサービスという言葉が注目されたように、サービスが小さなサービスの集合体となりつつあります。
 そうなると大切なのが、サービス間の連係です。連携方法としては、WebHookのような1対1の連係とプッシュ通知のような1対多の連係が多いのではないでしょうか。WebHookの場合は、API GatewayとLambdaの組み合わせで簡単につくれるようになりました。あと足りないのは、プッシュ通知の技術ではないかと思います。SNSやiOS,Androidのプッシュ通知はミリ秒というより数秒〜数分のDelay前提のような気がします。マイクロ秒単位のものが必要とされる場が増えてくると思います。HTTPであれば、WebSocket(サーバープッシュ)的なイメージです。この辺りをサービス化したものも既に幾つかあります。今年は、それをどう使いこなすかという部分に注目していこうかと思っています。まぁ何とも地味な分野で言語化が難しいのですが、今のところはその辺りを考えています。
 もう少し具体化すると、Electronのようなものの登場でPCの世界のアプリ化もより一層進むのかと思います。そして、PCにしろモバイルにしろ、その中のアプリの一つ一つがサービス化していくのだと思います。そこの部分をシームレスに連係していくところが何か鍵になるのではと思います。

具体的に強化する技術



 上記のような事を探求するのに今の私に足りてないのは、Node.js力ですね。JavaScript自体は解っているし、Nodeもある程度触っています。しかし、まだガッツリとは取り組んでいません。今年あたり本格的に取り組んで、筋の良い/悪いアプリ・アーキテクチャを見極められるよう目指します。さて、誰に弟子入りしよか。

See Also:
2015年の振り返りと2016年の目標
2015年の注目技術

2015年のブログのアクセスランキング

 2015年の振り返りと2016年の目標の方に書いているので、個々の記事の動向についてざっくりまとめておきます。

傾向と対策



 昨年の較べて、2015年の記事が増えました。理由としては検索流入が激減したので、はてブなどで一時的にバズったものが上位に出やすくなっているためです。フローよりストック重視なので、これは由々しき問題です。一方で2014年以前の記事で上位のものについては、検索でヒットするものです。この辺りの分析をして、改善したいですね。少なくとも「Rubyによるクローラー開発技法」とか「Amazon Web Services パターン別構築・運用ガイド」では上位に出したい。

2015年の振り返りと2016年の目標

 あけましておめでとうございます。今年もよろしくお願いします。今のうちに、2015年を振り返ってみます。2015年の外部に公開している活動は、出版1冊と雑誌寄稿2回、ユーザグループ等での登壇が7回、会社等でのセミナーでの登壇が2回です。

2冊目の本の出版



 まず出版ですが、「Amazon Web Services パターン別構築・運用ガイド」という本を会社の同僚たちで書きました。前作のRubyのクローラー本が好評だったので、もう一冊何か書かないと出版社から打診がありました。今度は、本業としてやっているテーマを扱い、会社名を出して出版することになりました。複数人で執筆することは調整事項も多く大変な部分がありましたが、それぞれ違ったバックグラウンドを持つ人間が集まることにより、自分の能力以上のものが出来上がったと思います。
 ちなみに発売したのが2015年3月25日なので、まだ10ヶ月経っていません。個人的な感覚的としては、もっともっと経過しているように思えます。これも、AWSの進化が早過ぎるためでしょうね。少しでも追いつけるように、増刷の度に修正していっています。また、クラウドネイティブな構成の普及が予想より速くなりそうなので、もう一冊AWS本を書くことにしました。今書いているので、乞うご期待!!

雑誌寄稿



 本の執筆以外にも、雑誌寄稿も行いました。WEB+DB PRESS Vol.88の特集で、「クラウドで加速!モバイル開発最前線」というタイトルで、モバイル開発の改善をテーマにしています。本業の方でモバイル開発もしているのですが、開発のサイクルが速く、かつ開発対象のアプリが増える一方という状況で、自動化できるところは自動化していこうと取り組んできたことをテーマにしています。編集者さんと話しているうちに、どうせだったら全部クラウド上のリソースを使ってやってみようという形になったので、結構挑戦的な構成になっていると思います。憧れのWEB+DBに寄稿できたので、非常に感慨深いものがありました。また企画・構成については考えたものの、実際の執筆は会社の同僚が殆ど買いてくれました。感謝感謝です。
 あと同じテーマをビジネス観点で書いたものを、会社の情報誌にも寄稿しています。3年ぶり2回目の寄稿ですが、前回に比べると校正時の指摘事項も殆どありませんでした。少しは文章書くことに慣れてきているのかもしれません。

登壇・発表



 イベントの登壇は、JAWSUG関係を中心に7回行っていました。内容はAWS中心ですが、RubyやDevLove、クラスメソッドさんと色々な主催者の方に呼んで頂けるようになってありがたいです。AWS本の共著者のメンバーも色々呼ばれるようになってきて、そちらも嬉しいです。(自分の発表より、かなり上手くて感心する一方です。)

www.slideshare.net
www.slideshare.net
www.slideshare.net
www.slideshare.net
www.slideshare.net
www.slideshare.net
www.slideshare.net

 この中では、Swaggerの話が一番苦労しました。苦しみまくったおかげで、だいぶ理解も進んでいます。強制的な学習という意味で良かったのではと思います。その他でも、仕事としてセミナーでの発表やクローズドな環境での発表を何度かしました。プレゼン資料の質は中々あがっていないのですが、発表すること自体にはだいぶ慣れてきました。今年は、プレゼン資料の質の向上をテーマの1つにします。

ブログ



 2015年は80本書いていたようです。2014年は82本なので、ほぼキープです。アクセス数では、2015年は241,741です。2014年は328,411だったので25%の減少です。更に言うと、2013年は674,188だったので、何とか回復させたいところです。原因としてはハッキリしていて、独自ドメイン変更後の検索流入の減少です。これ、本当に何とかしたいです。自分の本で検索しても、圏外というのは辛いです。

f:id:dkfj:20160101144019p:plain

 だれかアドバイスください。。。

2015年の目標に対しての採点



 2015年の目標は、これでした。

  • 本を1〜2冊出版する ⇒ △ 1冊だけ出版したので、最低限は実現できました。
  • Kindle本を書く ⇒ ☓ 駄目でした。
  • モバイル・アプリ再入門 ◯ 割りと取り組めました。ただ、仕込みの段階で終わってるので、今年は成果につなげたいです。
  • 資格試験 ☓ 全然だめでした。受験します。
  • ワークバランス △ 子供・家族と過ごす時間を、物理的に増やしたいです。2014年より改善したもののまだまだです。
  • ワイン・エキスパート ☓ 申し込みすらしていないです
  • 記録をしっかり △ 読書の記録はKindleのおかげで改善。ワインの記録を考えないと
  • 英会話 ☓ 自分の中での優先度は低いのかも
  • 犬を飼いたい ☓ まずは住居の問題の解決が必要。今年は解決できず

2016年の目標



  • 本を2冊書く ⇒ 執筆中の他に、もう1冊。既に企画が2〜3件打診されているので、どうすべきか。。。
  • Kindle本を書く ⇒ Kindle市場の興味があるので、ぜひ自前で出版して試してみる
  • AWS本の英訳 ⇒ 海外の技術書市場の調査のために、チャレンジしてみたい
  • 資格試験 ⇒ せめてAWS資格くらいは全部とります
  • ワークバランス ⇒ 定量的に図れるように、前年の推定値と本年の目標をだした上で実現する
  • メジャーイベントへの登壇 ⇒ Developer Summit等のメジャーイベントへの登壇。その為に、自分の強みの分野の再定義
  • 健康 ⇒ 全ての活動の基本は、やはり健康。その為の運動。これを定量的に測定する。

細かい部分や、仕事等で公開できない部分については、別途管理します。

まとめ



 何となく去年の延長ですが、1つ1つ出来ることを増やすというのがモットーです。亀の歩みかもしれませんが、地道にやっていきます。今年もよろしくお願いします。


追記:2016/01/02
2015年のブログアクセスのランキングも記載しました。
2015年のブログのアクセスランキング

追記:2016/01/03
2016年の注目技術を記載しました。
2016年の注目技術 - プログラマでありたい

"人工知能は人間を超えるか"のKindleセール99円が面白い

 最近注目しているのが、Kindle角川セールで行われている"人工知能は人間を超えるか"の99円セール。この本は、紙の本であれば1,512円ですが、Kindleのセールで何と99円。さらに19%ポイント還元です。95%以上OFFと、類を見ないセール内容となっています。

人工知能は人間を超えるか (角川EPUB選書)

人工知能は人間を超えるか (角川EPUB選書)

このセールが面白いと思う理由



 私がこのセールを面白いと思う理由は、この本が本来買うであろう顧客層を突き抜けて、広範囲に売れていると推測しているからです。本というのは、実は元々想定する読者層の中で如何に買われるかが勝負になります。例えば、SF小説というカテゴリーを買う人は一定数いて、逆に一定数以上の人は買いません。顕著な例だと、医学書で特定の症例を題材にした場合、恐らく読者層はせいぜい数百人くらいで、ヘタしたら著者は読者のことを殆ど知っているのではないかという場合もありそうです。コンピューター系の技術書も、カテゴリーが細分化されていて初版の3,000冊売れればやれやれということも多いようです。
 この人工知能というテーマも、本来であればそれほど大きな購買層を持っているとは思えません。もちろん、ビッグデータや機械学習といった言葉が一般紙にも載るようになったので、興味を持たれる下地はあると思います。しかし、Kindleの有料ストアランキングの1位に君臨し続けるパワーはなかったはずです。それが上手な価格戦略のおかげで長期にわたって1位になっています。また紙の本も3桁順位の前半をキープし続けるなど、大健闘です。
※Amazonの紙の本のランクで、3桁順位は飛ぶ鳥を落とす勢いです。

このセールは、成功なのか?



 つまりこのセールは、大成功なのではと思います。この本は2015年3月に発売され、かなりのヒットを続けていました。レビュー数からみても解るとおり、かなりの好評価を得ています。この時点で、この本のポテンシャルに気がついた/もしくは一気にベストセラーを目指そうと、今回の目玉企画につながったのでしょう。実際、このセールで買っている人は、本来であれば買わなかった人が9割くらいなのではと思います。(私もその一人です。)Kindle本が売れているとなると、引きつられて紙の本が売れます。まだまだ大多数の人が、本は紙で読みたいという人がいるからです。
 出版社としては、Kindle本は利益が出ないor損失だけど、もともと売れない層に売っているから敢えて目をつぶれます。その分、紙の本が売れてくれれば万々歳です。見事にその戦略があたっているのではないでしょうか?

Kindleのセールの場合、印税はどうなるのか?



 ちなみにKindleのセールの場合、印税はどうなるのでしょうか?セール以外の話をすると出版社によって違いますが、紙の本の印税は8〜10%くらいでしょう。また、Kindle版は、その倍の16〜20%くらいというのが多いようです。例えば、1500円の本で10%の印税であれば、1冊売れれば150円です。Kindle版は紙の本より安く設定されることが多いですが、例え半額でも同程度の印税が貰えるように設定されることが多いようです。
 さてセールの場合です。実はセールで安売りしていても、著者に入る印税は元々の価格をベースにしたものが多いようです。つまりセールと関係なく正規の印税が手に入るということです。この辺りは、別途詳しく解説しようと思います。

本のマーケティングに思う所



 今まで出版社は、マーケティングという意味でのマーケティングは殆どしていませんでした。また、再販価格維持制度があるので、(ハードカバー、文庫本という意味以外)価格戦略というのも殆ど取っていません。Kindelの登場により、この辺りが一気に変わるのではと思えてきました。技術書というニッチな市場の著者としては、印税よりかは如何に多くの人に届くのかという方が興味があります。その辺り考えると、Kindle直販など色々試してみたくなります。その考えのキッカケになるセールでした。

人工知能は人間を超えるか (角川EPUB選書)

人工知能は人間を超えるか (角川EPUB選書)

See Also:
上級者向けの技術書が少ない理由
一介のブロガーが技術書を書くに至った経緯。或いは自分戦略
本を書く前に準備したこと、執筆中にしていたこと
『Rubyによるクローラー開発技法』を書きました
『Amazon Web Services パターン別構築・運用ガイド』を書きました

iPadがノートPCの代わりにならない理由

 初代のiPadの購入から、iPad miniやiPad Proなど公私ともに使ってきました。またiPadにキーボードを付けて、ノートPCの代替として使えないか試行錯誤してきました。今の所の結論は、ノーです。

iPadを利用したい動機



 東京転勤以来、始発駅から通っている為に座って通勤しています。結構まとまった時間があるので、そこを有効活用する方法を考えていました。結論的には、どこでも原稿やブログを書ければ一番効率的な時間の使い方だと思い至りました。読書とかも隙間時間の使い方の1つですが、日中の移動や帰りなど座れない時も結構あるのでそちらの時間を当てています。
 平日毎日30分あれば、月に10時間確保できます。私は、だいたい1時間で4,000字くらいは書けるので、ページ数にして25頁くらいの分量です。これだけ書ける時間を捻出できたら万々歳です。(実際に書けるかは別ですが。)

iPadがノートPCの代わりにならない理由



 ということで、最初はiPad miniを持ち歩いて試行しました。最初からキーボードがないと、まともな活動が出来ないと思っていたのでカバー一体型のキーボードを購入しています。LOGICOOLの一体型のを選びましたが、これ自体は非常に良かったです。今でも利用しています。
LOGICOOL ウルトラスリム キーボード フォリオ for iPad mini ブラック TM725BK

LOGICOOL ウルトラスリム キーボード フォリオ for iPad mini ブラック TM725BK

 しかし、すこぶる生産性が低いのです。要因としては、主に下記の2つです。

  • コピー&ペーストすらやりにくい
  • ショートカット・キーの概念が無い

 特に後者が致命的でした。私は何か作業する時に、いろいろなモノを参照しながら考えます。その際の切り替えがショートカット・キーの概念がないiOSだと非常に不便でした。iPad Proだと2画面利用可能で不便を解消できるかもしれませんが、あの大きさを持ち歩く気にはなりません。

試行錯誤の結果



 11インチのMacbook Airを常時持ち歩くようになりました。また、手提げのカバンだと、他の荷物を入れるとそれなりに重くなるので、リュックに切り替えました。結果的に全く不便がなくなりました。iOSよりMac OSの方が便利ですね。そういう意味で、Surface Bookが気になっています。

感想



 やっぱりPCは便利。でも、人によってはiPadで充分という人も増えると思います。

プログラマになりたい Advent Calendar 2015 - Qiita
プログラマになりたい Advent Calendar 2015 - Adventar