プログラマでありたい

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

JAWS-UG さいたま支部で、「サーバーレス化を支える認証認可の話」という話しをしてきました。

 1/13にJWAS-UGさいたま支部第9回で、「サーバーレス化を支える認証認可の話」という話しをしてきました。

サーバーレス化を支える認証認可の話


 API GatewayやCognitoを利用する際にAWSの機能でどんな認証方法があるのか、あるいはアクセス制限ができるのかという話しをまとめています。認可の話しは全くしていないので、ちょっとタイトルを盛りすぎたと反省しています。

speakerdeck.com

この話の背景


 最近、フィンテックだなんだでシステムをAPI経由で利用できるようにして、外部公開したいという話しが増えています。その際に聞かれることが多い事例を挙げています。個人的な印象だと、認証とアクセス制限をごっちゃにしている人が多いのですね。またアクセス制限についての相談も多いです。個人的にはアクセス制限は気休めの場合が多いので、そこから考えるのは悪手だと考えています。一方で、既存のシステムとのセキュリティポリシーとの兼ね合いで、対応せざるを得ないという事情も解ります。ということで、悩む前にこれ読んでもらって、調べる時間が短縮されればと思います。

認可の話


 資料書いているうちに、アクセス制限の方に頭がいって認可の話しを書くのを忘れていました。どこかのタイミングで追記しようと思います。簡潔にまとめると、IAMはユーザーとAWSリソースの認証認可のサービスなので、これを使ってアプリケーションの認証認可に使うのは向いていません。Cognitoのフェデレーション機能使ってトークンの運用を楽にして、アプリケーションの認可は自分で作り込むという形になります。このあたりの話しに需要があれば、ブログ等でまとめたうえで電子書籍化してみたいなと思っています。ベースは2年前くらいに考えていた、この記事になります。
AWSとシステムの認証認可を考える

まとめ


 久しぶりのJAWSUGの登壇でした。準備不足で痛い目にあいましたが、やっぱり楽しいですね。去年サボったので、今年は対外発表を頑張ろうと思っています。お気軽にお声がけください。
 あと最後に宣伝ですが、Amazon Web Services 業務システム設計・移行ガイドが今週発売です。こっちはAWSのアカウント管理とかネットワーク設計、データ移行とオンプレミスと正面から向き合った1冊です。ぜひぜひギャップを楽しんでください。

Amazon Web Services 業務システム設計・移行ガイド

Amazon Web Services 業務システム設計・移行ガイド

  • 作者: NRIネットコム株式会社:佐々木拓郎,林晋一郎,株式会社野村総合研究所:瀬戸島敏宏,宮川亮,金澤圭
  • 出版社/メーカー: SBクリエイティブ
  • 発売日: 2018/01/20
  • メディア: 単行本
  • この商品を含むブログを見る


See also:
Amazon Web Services 業務システム設計・移行ガイドの目次
「Amazon Web Services 業務システム設計・移行ガイド」という本を書きました

Amazon Web Services 業務システム設計・移行ガイドの目次

 お正月に筆者陣にてAmazon Web Services 業務システム設計・移行ガイドの最終校正をおこなっていました。これで私の作業は終わりで、後はいよいよ発売を待つ限りです。発売日は、2018年1月20日の予定です。目次も確定したので、細かい部分含めて公開します。

Amazon Web Services 業務システム設計・移行ガイドの目次


Chapter1 AWSサービスの概要
1-1 AWSとは
 AWSのサービスの特徴
 AWSとオンプレミスの違い
  ・所有と利用
  ・キャパシティ設計
  ・クラウドサービスの見分け方
 AWSのメリット
  ・スモールスタートで始められて、駄目だったら捨てられる
  ・インフラ構築のスピードを加速できる
  ・事前に多めのリソースを確保する必要がなくなる
  ・AWSのメリットは、「早めに失敗する」が可能なこと
1-2 AWSのサービスの全体像
 AWSの基本的な考え方
 リージョンとアベイラビリティーゾーン
  ・リージョン
  ・アベイラビリティーゾーン
 VPCとDirect Connect
  ・VPC
  ・Direct Connect
 AWSアカウント
  ・単一アカウント
  ・複数アカウント
 AWSでの監査証跡
  ・AWSにおける監査証跡の対象
 AWSの料金
  ・AWSの料金体系
  ・AWSの無料枠
  ・AWSの料金計算ツール「Simple Monthly Calculator」
  ・一般的な構成での利用料金の内訳
1-3 主なAWSサービス
 コンピューティングサービス
  ・仮想サーバ「EC2」
  ・サーバレスなコンピュータ処理基盤「Lambda」
 ストレージサービス
  ・オンラインストレージボリューム「S3」
  ・ファイルストレージボリューム「EFS」
  ・S3へのデータ転送機能「Storage Gateway」
 データベースサービス・データ処理サービス
  ・Amazon RDS
  ・AWSのNoSQLサービス
 ネットワークサービス
  ・プライベートネットワーク機能「VPC」「Direct Connect」
  ・DNSサービス「Route 53」
  ・CDNサービス「CloudFront」
 AWSの管理ツール
  ・テンプレートによる自動構築ツール「CloudFormation」
  ・AWSの利用状態の管理ツール「CloudTrail」「Config」
  ・サポートサービス「Trusted Advisor」「AWSサポート」
 AWSへ移行するためのサービス
  ・データ移行サービス「DMS」
  ・大量データの持ち込みサービス「Snowball」
 アカウント管理
  ・AWSのアカウントの種類
  ・AWSアカウント
  ・IAMユーザー
  ・組織アカウント(AWS Organizations)
 セキュリティツール
  ・継続的セキュリティ評価ツール「Inspector」
  ・無料のサーバ証明書発行ツール「Certificate Manager」
  ・DDoSやアプリケーションレイヤーの防御「WAF」「Shield」
 通知&監視サービス
  ・通知サービス「SNS」
  ・監視サービス「CloudWatch」

Chapter2 全体設計(管理方針と移行計画)
2-1 アカウントの管理の考え方
 AWSアカウントとIAMユーザー
  ・AWSアカウント
  ・IAMの構造
  ・一時的な権限付与とクロスアカウントロール
 複数のAWSアカウントを管理する
  ・一括請求機能「Consolidated Billing」
  ・組織アカウント(AWS Organizations)
2-2 AWSと監査証跡
 システムのログ・操作履歴
 AWSのログ・操作履歴
2-3 AWSのネットワーク設計の考え方
 VPCの位置づけと社内ネットワークとの接続方法
  ・社内ネットワークの形態
  ・VPCをどう接続するか
  ・拠点とVPCの接続
 複数のAWSアカウント間の接続方法
  ・用途別のAWSアカウントの分類と接続方法
  ・VPCピアリングを利用したAWSアカウント間の接続
2-4 AWSへのシステム移行
 クラウドジャーニー:移行のステップ
 AWS移行のパターン
  ・単純移行
  ・カスタマイズ
  ・最適化
 AWSへの移行計画
  ・フィット&ギャップ分析
  ・導入コンサルティング(AWSプロフェッショナルサービス)
  ・机上検証は最小限に
 AWSの移行サービス
  ・サーバの移行
  ・データの移行
  ・データベースの移行
2-5 AWS上のシステムの監視・運用
 AWS上のシステムの監視の考え方
  ・システムの監視対象
  ・CloudWatchを使った監視
  ・SNSを使った通知
 AWSの運用サービス
  ・インスタンスの状態管理・運用「Systems Manager」
  ・インスタンスのセキュリティ評価「Inspector」
  ・サポートサービス

Chapter3 アカウント管理と権限付与
3-1 AWSのアカウント管理
 効率的にアカウントを管理する
 AWS Organizations
  ・AWS Organizationsを用いたAWSアカウントのグルーピング
  ・AWS Organizationsの機能
  ・アカウントの作成
  ・請求の一元管理
  ・アカウントで利用するAWSサービスに制限をかける
  ・JSON形式の権限設定
  ・ポリシージェネレータ
 AWS Organizationsの導入とポリシーの設定
  ・マスターアカウントでOrganizationを作成
  ・Organizationに紐付けるアカウントの設定
  ・Organization Unitの作成と階層構造の定義
  ・サービスコントロールポリシーの作成とアタッチ
 AWS Organizationsのベストプラクティス
  ・マスターアカウントでCloudTrailを有効にする
  ・マスターアカウントはアカウント管理専用にする
  ・Organization Unitにサービスコントロールポリシーをアタッチして権限を制限する
・Organization内でホワイトリストとブラックリストを混在させない
 アカウント管理のロードマップ
  ・管理主体と管理する範囲を決定する
  ・Organizationを管理する担当を決定する
  ・権限付与のルールを作成する
  ・Organization Unitの構成設計を行う
3-2 AWSの環境分離
 環境をアカウントで分割するメリット
  ・運用面のメリット
  ・コスト管理におけるメリット
 環境をアカウントで分割するデメリット
  ・運用面のデメリット
  ・コスト面のデメリット
 特別なポリシーがない場合の分割のベストプラクティス
3-3 AWSの権限管理
 IAM(Identity and Access Management)
  ・IAMポリシー
  ・IAMポリシーの作成
  ・IAMユーザーとIAMグループ
  ・rootユーザーの扱い
 マネジメントコンソール以外からAWSサービスを操作する
  ・アクセスキーとシークレットキーを用いて、AWSリソースを操作する
  ・アクセスキーとシークレットキーの作成
  ・CLIのインストール
  ・CLIの設定(アクセスキー・シークレットキーの設定)
  ・AWSリソースへのアクセス
 キー漏洩の対策
  ・IAMロール
 Amazon Cognito
  ・Cognito Identity
  ・Cognito Identityを用いた認証と認可の流れ
  ・User Pools
  ・Federated Identities
  ・Cognito Sync
 AWSにおける権限管理のベストプラクティス
  ・役割ごとのIAMグループで権限を管理する
  ・利用者ごとにIAMユーザーを払い出す
  ・割り当てる権限は、必要最低限のものにする
  ・権限やIAMユーザーについては定期的に棚卸しし、最適な状態を保つこと
  ・その他、これまでに記載してきた下記のルール

Chapter4 ネットワーク接続の設計・構築・維持管理
4-1 AWSネットワークの全体構成
 AWSネットワークの構成要素
  ・VPC
  ・インターネットにおけるAWSサービスへの接続
 通信要件
  ・通信内容の整理
 物理構成
  ・VPCの位置づけ
  ・VPCをどこに接続するか
  ・インターネットをどこに接続するか
 論理構成
  ・アドレスアサイン
  ・VPCが幾つ必要か
 サービスの選定
  ・インターネットVPN
  ・Direct Connect
4-2 ネットワーク設計
 アドレス設計
  ・VPCに割り当てるCIDRブロック
  ・サブネット
 ルーティング設計
  ・AWSのルーティング要素
  ・ルートテーブル
  ・local
  ・インターネットゲートウェイ(Internet Gateway)
  ・VPNゲートウェイ(Virtual Private Gateway:VGW)
  ・ピアリング接続
  ・稼働中のEC2インスタンス
  ・VPCエンドポイント
 フィルタリング設計
  ・ルーティングによるフィルタリング
  ・VPCのフィルタリング機能を用いたフィルタリング
 名前解決とDHCPオプションセット
  ・グローバル(インターネット)への名前解決の必要性
 ロードバランサー設計
  ・ELBのメリット・デメリット
  ・仮想アプライアンスのメリット・デメリット
  ・ELB(ロードバランサーサービス)
  ・ELBの基本的な機能
  ・ELB利用時のポイント
 パケットキャプチャとVPCフローログ
 Route 53
  ・権威DNSサーバ機能
  ・ルーティング機能
  ・ヘルスチェック機能
  ・ドメインの登録(取得)

Chapter5 システム設計とサービスの導入
5-1 AWSサービスを利用したシステム設計
 オンプレシステムとの連携を伴わないECサイト
  ・アカウント
  ・VPC、サブネット
  ・Webサーバレイヤー
  ・データベースレイヤー
  ・バッチサーバ
 ハイブリッド環境で運用する基幹システム
  ・インターネット接続とセキュリティ
  ・紹介するアーキテクチャパターン
5-2 Web可用性向上パターン
 ELB
  ・ELB自体のスケーリング
  ・ヘルスチェック機能
  ・スティッキーセッション
  ・Connection Draining
 Auto Scaling
  ・Auto Scalingの設定項目
  ・Auto Scalingグループ
  ・起動設定
  ・Scalingポリシー/プラン
 Web可用性向上パターン
  ・パターン導入のポイント
 ELBとAuto Scalingの利用方法
  ・ELBの利用方法
  ・Auto Scalingの利用方法
  ・Auto Scaling設定の確認
5-3 コンテンツキャッシュパターン
 Amazon CloudFront
 CloudFrontとAWSサービスの連携
  ・各種セキュリティサービスとの連携
  ・Amazon API Gatewayとの連携
  ・Lambda@Edgeとの連携
 コンテンツキャッシュパターン
  ・キャッシュTTLを正しく設定する
  ・Popular Object Reportを参考に定期的に設定の見直しを行う
  ・オリジンサーバの障害を考慮した設計を行う
  ・CloudWatchを設定してアラームを受け取る
 CloudFrontの利用方法
  ・S3の静的ホスティングの設定
  ・CloudFrontの設定
  ・CloudFrontの設定の確認
5-4 DB可用性向上パターン
 RDS
  ・RDSを用いるメリット
  ・RDSを用いるデメリット
  ・「RDS」vs「. DB on EC2 with CLUSTERPRO」
 DB可用性向上パターン
  ・運用のポイント
  ・マスター・スレイブ構成にすることでメンテナンス時間を短くする
 RDSの利用方法
  ・マルチAZにマスターDBとスレイブDBを配置する
5-5 インメモリキャッシュパターン
 ElastiCache
  ・ElastiCache for Memcachedの特徴
  ・ElastiCache for Redisの特徴
 インメモリキャッシュパターン
  ・導入する際のポイント
 ElastiCacheの利用方法
  ・Memcachedの作成
  ・Memcachedの設定
5-6 ジョブサーバパターン
 ジョブサーバパターン
  ・構築のポイント
 NATゲートウェイの利用方法
  ・NATゲートウェイの作成
  ・ルートテーブルの編集
 VPCエンドポイントの利用方法
  ・VPCエンドポイントの作成
  ・VPCエンドポイントの設定
5-7 ハイブリッド利用パターン
 インターネット接続設計
  ・VPC内からインターネットへアクセス
  ・サブネット設計
 ハイブリッド利用パターン
  ・AWS環境への移行方法
  ・システムの一部をAWS環境に移行するパターン
  ・システム全体をAWS環境に移行するパターン
5-8 ファイルサーバ利用パターン
 ファイルサーバ利用パターン
  ・全体の構成
  ・ネットワーク設計
 Storage Gatewayの利用方法
  ・ファイルゲートウェイサーバの作成
  ・バックアップ先のS3の設定
  ・クライアントからファイルゲートウェイをNFSマウント
  ・注意事項
5-9 大規模データ分析パターン
 RedshiftとBIツールを利用した大規模分析
 大規模データ分析パターン
 Redshiftの利用方法
  ・サンプルデータのS3アップロード
  ・テーブルの作成とデータのインポート
  ・サンプルデータのロード
  ・BIツールからのRedshift接続
5-10 インフラ構築を自動化する
 AWSのインフラ構築自動化サービス
  ・AWS CloudFormation
  ・AWS OpsWorks
  ・AWS Elastic Beanstalk
  ・サービスの使い分け
 CloudFormationを用いたインフラ自動構築
  ・CloudFormationの機能概要
  ・CloudFormationの組み込み関数
  ・セクション 268 CloudFormationのベストプラクティス
  ・セキュリティ面のベストプラクティス
  ・テンプレート設計・作成面のベストプラクティス
  ・運用面のベストプラクティス
 AWS OpsWorks
  ・OpsWorksスタック
  ・OpsWorks for Chef Automate
 AWS Elastic Beanstalk
  ・All at Onceデプロイ
  ・Rollingデプロイ
  ・Rolling with additional batchデプロイ
  ・Immutableデプロイ
  ・URL Swapでの切り替え
  ・Route 53での切り替え

Chapter6 移行テクニック
6-1 移行する資産
6-2 データの移行
 データ移行にかかる時間の目安
 AWSのサービスを使わないデータ移行
  ・OSコマンドを使ったデータ移行
  ・CLIを使ったデータ移行
 AWSのサービスを使ったデータ移行
  ・Storage Gatewayを使う
  ・Snowballを使う
  ・Snowball Edge
  ・Snowmobile
6-3 仮想サーバを移行する
 AWS Server Migration Service
  ・SMSの構成概要
  ・VM Import/Exportとの違い
  ・SMSの特徴
  ・OSのライセンス
6-4 データベースを移行する
 AWSのサービスを使わずにデータベースを移行する
 AWS Database Migration Service
  ・DMSの構成概要
  ・DMSとオンプレミスサーバ間の接続経路
  ・同一データベースシステム間の移行
  ・異なるデータベースシステム間の移行
  ・データの移行と移行後のデータ同期

Chapter7 運用監視の設計・実施
7-1 システムを監視する
 CloudWatchを使う
  ・標準のメトリクスで監視する
  ・カスタムメトリクスを使って監視する
  ・オンプレミスサーバの監視との比較
  ・AWS特有の監視
 CloudWatch Logsを使う
  ・エージェントのインストール
  ・監視対象ログの設定
  ・エージェントの起動
  ・CloudWatch Logsへ転送されたログの確認
  ・特定文字列の検知
  ・CloudWatch Logsの他サービス連携
 CloudWatch Eventsを使う
  ・EC2インスタンスのスケジュールイベント通知
  ・イベントバス
7-2 システムを運用する
 AWSサポート
  ・インフラストラクチャイベント管理(IEM)
  ・サポートへの問い合わせ方法と応答時間
  ・リソース制限の増加申請
  ・サードパーティ製ソフトウェアサポート
 AWS Personal Health Dashboardを使う
 AWS Trusted Advisorを使う
  ・チェック結果の通知
  ・サービス利用制限のチェック
 Amazon Inspectorを使う
  ・Inspectorの実行
 Amazon EC2 Systems Managerを使う
  ・SSMが提供するサービス
7-3 システムの履歴を管理する
 AWS CloudTrailを使う
  ・CloudWatch Logとの連携
  ・CloudTrailを設定する
 AWS Config/Config Rulesを使う
  ・サービス連携
  ・ルールの作成
  ・Configを設定する
  ・履歴の確認

Amazon Web Services 業務システム設計・移行ガイドの目次の解説



1章 AWSサービスの概要

 1章は、AWSの基本的な考え方やサービスの説明です。オンプレに較べてのAWSや、リージョンやアベイラビリティゾーンなど基本的な概念から、AWSアカウント・ネットワーク・料金体系など一番基本的な部分を説明の上で、主要なサービスを説明しています。注目して欲しいのが、ピックアップしたサービスです。EC2やS3、RDSというお馴染みのもの以外にも、Snowball・DMS・AWS Organizations、Inspectorなど余り耳にする機会が少ないものもあります。これは、企業内で導入する際には是非抑えておいて欲しいサービスを選んだ結果です。この辺りのサービスを解説している書籍は、結構少ないのではと思っています。

2章 全体設計(管理方針と移行計画)

 2章は全体設計ということで、本書の基本的な考え方を紹介しています。AWSアカウント管理、監査証跡、ネットワーク設計、システム移行、監視・運用の5つの節で構成されています。ここで概要を説明した上で、後の章で個別・具体的に構築方法含めて紹介しています。

f:id:dkfj:20180108162954p:plain

3章 アカウント管理と権限付与

 3章からがメインのコンテンツです。3章は、AWSのアカウントの管理でAWS Organizationsからアカウント分割の方針、IAM・Cognitoと紹介しています。ここでは概念だけではなく、具体的な設計、ポリシー例を挙げたいます。AWS Organizationsについては、基本的な機能から具体的なサービス制限の仕方、ベストプラクティス等にも言及しています。何とAWSのアカウントだけで、50ページを割いているいます。

f:id:dkfj:20180108162448p:plain

4章 ネットワーク接続の設計・構築・維持管理

 4章はAWSにおけるネットワーク設計です。AWS内のVPC内に留まらず、オフィス・データセンターと全体がある中で、AWSのネットワークをどう位置づけるか、その視点での設計の紹介となっています。AWS本は数あれど、この視点で解説している本は少ないと思います。ここの部分を、2012年からAWS Direct Connect ソリューションプロバイダーとしてサービスを運用・提供してきた実担当者によって、詳しく解説されています。世の中、Direct Connectを使ったことがある人は数多くいると思いますが、Direct Connectのサービスを提供している人は殆どいません。そういった意味で、現場での知識・ノウハウが沢山散りばめられています。

f:id:dkfj:20180108162150p:plain

5章 システム設計とサービスの導入

 5章は具体的なシステム設計です。企業内で使われることが多い構成を念頭に、どのように設計するのがよいのかパターン別に紹介しています。AWS単体の設計のみならず、オンプレミスとのハイブリッド構成の場合どうするかといった事が随所に書かれています。一番ニーズの多い、WebサーバやDBサーバの可用性やスケーリングの方法、大規模運用であれば欠かせないコンテンツキャッシュなどWeb寄りの話から、ジョブサーバやファイルサーバ、或いはハイブリッド構成の場合にどのようにインターネットに接続させるかなど実用的なテーマもあります。それ以外にも、Redshiftによる大規模データ分析や、AWSのサービスを利用したインフラ構築の自動化など、様々なテーマがあります。この章が読んでて一番楽しい部分だと思います。

f:id:dkfj:20180108165722p:plain

6章 移行テクニック

 6章は一転して、移行の話です。多くの場合、企業内のシステムは新規で一から作るのではなく、既存のシステムからの移行、或いは連携が必要になってきます。もっと言うと、データをどう移行するのか。そういった時に直面するのが物理の壁です。例えクラウドサービスといえども、何十TBのデータを一瞬で移行することは出来ません。物理的なファシリティの制約を受けます。例えば、既存のデータセンターの回線が100MBとすると、その回線を専有したとしても10TBのデータを移行するのに1週間以上掛かる訳ですね。現実的には、専有は出来ないし、1週間システムを止めておける訳でもないのでドンドン差分データが増えていきます。
 では、どうしたら良いのかというのを、あの手この手で解説しています。主にデータの移行・仮想サーバの移行・データベースの移行の3つに別けられていますが、根底とする部分は同じです。サービス止めないで、システム移行してねとサラッと言われ続けてきた辛みに対するノウハウの結集です。

7章 運用監視の設計・実施

 最後の7章は、AWS上にシステムを構築/移行した後の運用を見据えた話です。オンプレの運用監視と何が同じで違うのか、その視点での説明です。CloudWatchなど比較的お馴染みの話から、AWSサポートの使い方やTrusted Advisorなど運用始まったら必ず使うサービスや、Inspector, EC2 System Managerなどこれから主流になっていくサービスにも言及しています。

感想


 改めて目次を見返すと、我ながらよくまとまっていると思います。この内容は、私一人では決して書けなかったです。AWSの各分野のプロフェッショナルが集結した結果、この本が出来上がったと思います。最後にはなりますが、AWSの設計をする上で、ただ1つの正解というのはありません。利用者を取り巻く環境・制約によって、最適な解は変わってきます。本書では、その前提に立ちつつも、できるだけ多くの人に役立つよう企業への導入時のあるあるを思い出しながら書いています。是非、みなさん読んでみて感想きかせてください。


See Also:
「Amazon Web Services 業務システム設計・移行ガイド」という本を書きました
「この一冊で全部わかるWeb技術の基本」の監修をしました
「データを集める技術」という本を執筆しました
アプリケーションエンジニア向けのAWS本を書きました
『Amazon Web Services パターン別構築・運用ガイド』を書きました
『Rubyによるクローラー開発技法』を書きました

「勘違いをなくせば、あなたのホームページはうまくいく」を読みました

 著者の中山さんに「勘違いをなくせば、あなたのホームページはうまくいく」を頂きました。ありがとうございます。

f:id:dkfj:20180108221426j:plain

対象読者


 この本は直接的には自社ホームページの運用を改善する為の指南書です。その為に対象読者は、次のような方となっています。

・ウェブ活用がなかなかうまくいかない中小企業の経営者
・がんばってホームページを作ったのに,売上が増えずに困っているWeb担当者
・本やネットで必死に学んだのに,ホームページやWebで成果を出せずに悩んでいる方

 一方で、私はもっと色々な人に読んで貰えると良いと思っています。この本は、実は目的をどのようなプロセスで達成するかを書いた本なのです。そのプロセスの具体例としてはホームページ運営を使っていますが、他の分野でも充分応用が聞くと思います。私も、この本を読んでいて、直接的にはこのブログの改善のことを考えましたが、それ以外に現在の仕事を拡大させる為の戦略・道筋を考えながら読んでいました。

「勘違いをなくせば、あなたのホームページはうまくいく」の構成


 上記の通り、単純なSEOのように如何にホームページの集客力を集めるかというテクニックの話ではないです。利用者目線でホームページを作る時にどういう心理になるのか、またそこで陥りやすい行動は何か筆者のWebコンサルタントとしての豊富な経験を元に1つ1つ具体例をあげて解説しています。章立てとしては次の10章構成で、章タイトルも全てユーザーが陥る勘違いをベースとなっています。

第1章 ホームページのビジネス活用に関する勘違い
第2章 社内体制・ウェブ担当者に関する勘違い
第3章 パートナー会社選びの勘違い
第4章 ホームページ制作に関する勘違い
第5章 コンテンツ作成に関する勘違い
第6章 集客に関する勘違い
第7章 SEOに関する勘違い
第8章 広告に関する勘違い
第9章 アクセス解析に関する勘違い
第10章 オフラインとの関係に関する勘違い

 実はこの本、昨年末に頂いていました。思いの外読むのに時間が掛かって、感想書くのが随分と遅くなりました。私は自分で言うのも何ですが、結構読むスピードが速い方です。この本も一時間くらいで読めるかなと思ってたのですが、その何倍も掛かりました。理由としては、自分が知らないことが沢山あって色々驚きながら考えながら読んでいた為です。

著者の中山陽平さんについて


 ところで、著者の中山陽平さんについてです。中山さんはWebコンサルタントとして独立・会社設立をしていて、600社50業種以上のコンサルティング経験があると非常にWebに関して造詣の深い方です。私は中山さんの前職時代に仕事を通じてお付き合いがあり、独立後もSNSを中心にやりとりが続いています。
 この中山さん、とにかく頭の良い方です。それでありながら現場主義で、まず自分が経験して考えるということを徹底されています。PodcastとかWebでの連載とか色々あるので、興味を持った方はまずググってみてください。
 

どんな形式で解説しているのか?


 ちょっと本の内容から外れた話ばかりしていたので、具体例を1つあげます。4章のホームページ制作の勘違いの中に、「扱っている商品をすべてホームページに載せないと機会損失になる?」という問があります。これに対しての答えが、全ての商品を並列に扱っても意味がなくサービスを分類した上で導線を考えることの重要性が説明されています。
 まず商品やサービスをフロントエンド・ミドルエンド・バックエンドの3つに別けます。フロントエンドは、一番最初に売れるもので買い手にとっても買いやすいものです。ミドルエンドは、その次に買うもの。バックエンドは、ファンになってくれた人が買うものと定義しています。これを中山さんのサービスの実例を元に、導線設計を解説しています。主力製品がバックエンドだったとしても、それだけを一生懸命説明しても意味がないって話ですね。私自身陥りがちな事なので、身につまされました。

f:id:dkfj:20180108230242j:plain

感想


 とりあえず一読しましたが、折に触れて何度か読み直そうと思います。実践して上手くいかなければ、もう一度読み直して立ち返るというスタンスの本かなと思います。あと読んでいて、私もいつか技術書ではなくビジネス書を書いてみたいなと思いました。私はAWSやクローラーによる情報収集技術を得意としているのですが、じゃぁそれを使ってビジネスにどう活かすのか、そんな視点で考えてみたいと思います。宣伝ですが、AWS本の第三弾、「Amazon Web Services 業務システム設計・移行ガイド」がもうすぐ発売します。こちらもよろしくお願いします。

勘違いをなくせば、あなたのホームページはうまくいく ~成果を上げるWeb制作・ネット集客・販促戦略の心構え

勘違いをなくせば、あなたのホームページはうまくいく ~成果を上げるWeb制作・ネット集客・販促戦略の心構え

Amazon Web Services 業務システム設計・移行ガイド

Amazon Web Services 業務システム設計・移行ガイド

  • 作者: NRIネットコム株式会社:佐々木拓郎,林晋一郎,株式会社野村総合研究所:瀬戸島敏宏,宮川亮,金澤圭
  • 出版社/メーカー: SBクリエイティブ
  • 発売日: 2018/01/20
  • メディア: 単行本
  • この商品を含むブログを見る

See Also:
Amazon Web Services 業務システム設計・移行ガイドの目次
「Amazon Web Services 業務システム設計・移行ガイド」という本を書きました
「この一冊で全部わかるWeb技術の基本」の監修をしました
「データを集める技術」という本を執筆しました
アプリケーションエンジニア向けのAWS本を書きました
『Amazon Web Services パターン別構築・運用ガイド』を書きました
『Rubyによるクローラー開発技法』を書きました

2017年の振り返りと2018年の目標

 あけましておめでとうございます。今年もよろしくお願いします。毎年恒例となってきているので、正月のうちに1年を振り返ってみます。2017年の主な活動は、出版2冊と雑誌寄稿2回、後は職務上の役割変更でした。

5,6冊目の本の出版


 まず出版ですが、5冊目の本としてイラスト図解式 この一冊で全部わかるWeb技術の基本の監修し2017年3月に出版しました。また、まだ発売はしていませんが自身6冊目の本、AWS本の第三弾として、Amazon Web Services 業務システム設計・移行ガイドを2018年1月に出版します。


 Web技術の基本は、その名の通りWebに関する入門書です。これからITエンジニアを目指す人や、なりたての人、或いはIT業界に入ったのでWebとはなんぞやと知りたい営業・企画の人など、非エンジニアでも読めるように意識して書かれています。そもそもWebと一口に言っても、現在では凄く範囲が広がっています。昔は、Webサイトと電子メールが解っていれば充分でしたが、今やスマホアプリやIoTもWebの副産物となっています。ITのニッチな分野であったWebが、今や大部分を占めるようになってきています。ということで、そんなWebを体系的に学ぶ為の一冊となっています。
 この本に関しては監修ということで、基本的には殆ど書いていません。NRIネットコムの後輩で、大学時代にしっかり情報工学を学んでいた2名に書いてもらいませいた。私はちょこっとコラムを書いたくらいで、初期の構成と後は出来上がってきたものを確認するという役割でした。しかし、出来上がったものも、よく書けていたので余りすることがなかったというのが正直なところです。
 今までAWS本やクローラー本と、どちらかと言えばニッチな分野の本ばかりに関わっていました。この本で初めて、IT本のメインストリームといえるような分野に関わらせて貰いました。感想としては、やはりメインストリームは読者層のボリュームが大きくて面白いです。こういった分野で自分に何ができるか、もう少し考えてみています。

イラスト図解式 この一冊で全部わかるWeb技術の基本

イラスト図解式 この一冊で全部わかるWeb技術の基本


 Amazon Web Services 業務システム設計・移行ガイドは、過去2冊のAWS本と違い技術ではなく「利用する人」にフォーカスした本です。これから社内でAWSを利用する方や、管理する方向けに書いた本です。AWS本は数あれど、どの本もAWSのアカウント1つで構築すること前提で書いているものが殆どです。しかし、企業内ではAWSのアカウントが5個10個とゴロゴロとしているのが現実です。それをどう管理するのか、実際の利用している事業部門も情報システム部門も頭が痛い問題です。その辺りを真正面から取り組んでいます。発売は、もう少し先ですが是非読んで頂ければと思います。

Amazon Web Services 業務システム設計・移行ガイド

Amazon Web Services 業務システム設計・移行ガイド

  • 作者: NRIネットコム株式会社:佐々木拓郎,林晋一郎,株式会社野村総合研究所:瀬戸島敏宏,宮川亮,金澤圭
  • 出版社/メーカー: SBクリエイティブ
  • 発売日: 2018/01/20
  • メディア: 単行本
  • この商品を含むブログを見る

雑誌寄稿


 今年も2回、日経クラウドファーストに寄稿しました。SQSの話とDynamoDB
NoSQLデータベース - Amazon DynamoDB | 日経クラウドファースト - AWS・Azure導入の先端技術情報-
の話です。SQSの話だけで特集を組める機会は中々ないので、わりとノリノリで書かせて頂きました。
 日経クラウドファーストの執筆陣は、AWSのプレミアパートナーを中心に集められています。本当に濃いメンツで、定例会議にいくと非常にためになる話が聞けます。勉強させて貰いながら、原稿も書かせて貰えているのでありがたい限りです。

職務上の役割変更


 2017年4月から所属する会社で部長になりました。あまり職務上の事は書けないけど、考えないといけないことは思っていた程はあまり変わらず、しかし感じ方はだいぶ変わったような気がします。この辺りは、どこかで一度整理しようと思います。ようやく少し慣れてきたので、来年は少し攻めていこうと思います。

ブログ


 2017年は何と18本のみでした。2016年は53本だったので、大幅減です。一方でブログのアクセス数は、2017年は228,420ページビューと2016年に対して62%増です。ブログの執筆数が減ったのは、AWS本絡みで執筆に対して大スランプに陥ったこと。書くリズムが完全に狂いました。その一方でアクセス数が増えたのは、長年の懸案であった検索減の原因が解消したこと。

f:id:dkfj:20180101013350p:plain

 顛末は、「3年近くGoogleからSEOスパム扱いされていて、ようやく解消した話」を見て頂ければ幸いです。本出版しだしてからの期間がゴソッと検索に掛からなくなっていたので、もったいない限りです。またせっかく検索されるようになってきたので、それに対応するコンテンツ増やそうと思いつつ書けていないので、ここは2018年は頑張りたいところです。

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


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

  • 本を2冊書く ⇒ ◯ ちょっと嘘くさいけど、とりあえず達成
  • Kindle本を書く ⇒ ☓ 今年も実現できず。こちらを優先すべきというのは解ってはいるものの。 
  • AWS本の英訳 ⇒ ☓ とりあえず実験的に英語ブログを立ち上げて、一記事だけ投稿してみた。これを継続から始めたい 
  • 資格試験 ⇒ ☓ 新3種が日本語化されていないのでスキップ。ワインエキスパート、申込みしなかった。
  • ワークバランス ⇒ △ ここはイーブンくらい。残業時間は前年度比で減らした。
  • メジャーイベントへの登壇 ⇒ ☓ 引きこもりすぎて、メジャーどころかイベント登壇ゼロ。
  • 健康 ⇒ △ FitBitを使いだして歩数・睡眠時間は意識しだした。走るとかは元々無理なので、出来るところを意識する。

2018年の目標



  • 本を2冊書く ⇒ 今年も2冊は書く。既に書籍企画が6〜7件あるので、どうこなすか考え中。
  • Kindle本を書く ⇒ 今年こそ。完全に自分でコントロールする本を書いてみたい 
  • ブログ ⇒ 40記事。400,000ページビュー目指す。 
  • 英語ブログ ⇒ 過去記事の翻訳を含め30記事。30,000ページビュー目指す。 
  • 資格試験 ⇒ 新3種が日本語化されたら受ける。ワインエキスパート、申込みする。
  • ワークバランス ⇒ 平均残業時間30時間未満。望み小さいけど、まずはここから。
  • 健康 ⇒ 睡眠時間平均7時間。週5で体操。1万歩/日
  • 3つ目の分野 ⇒ クローラー/AWS以外にもう1つ露出できるような分野を作る

まとめ



 まわりの凄い人を見ていると焦るけど、今年も自分ができる事を1つ1つやっていきます。

See Also:
2016年の振り返りと2017年の目標
2015年の振り返りと2016年の目標

「Amazon Web Services 業務システム設計・移行ガイド」という本を書きました

 AWS本の第三弾として、Amazon Web Services 業務システム設計・移行ガイドという本を書きました。その名のとおり、企業内でAWSを使うということにテーマを据えています。ユーザー企業の情シスの人も、事業部で直接AWSを使っている人も、或いはSIerでユーザー企業にAWSを提案している人にも読んで欲しい内容となっています。

Amazon Web Services 業務システム設計・移行ガイド

Amazon Web Services 業務システム設計・移行ガイド

  • 作者: NRIネットコム株式会社:佐々木拓郎,林晋一郎,株式会社野村総合研究所:瀬戸島敏宏,宮川亮,金澤圭
  • 出版社/メーカー: SBクリエイティブ
  • 発売日: 2018/01/20
  • メディア: 単行本
  • この商品を含むブログを見る

Amazon Web Services 業務システム設計・移行ガイドを書いた理由


 過去2冊AWSの本を書いていて、一冊目のAmazon Web Services パターン別構築・運用ガイドは、AWS上にサーバーサイドのシステムをどう作るのかをサービスを中心に解説しています。2冊目のAmazon Web Services クラウドネイティブ・アプリケーション開発技法は逆にアプリケーションエンジニア目線で、AWSのサービスを使ってどうやって楽してアプリを作るかという本です。
 3冊目であるAmazon Web Services 業務システム設計・移行ガイドは、技術ではなく利用する人をベースにしています。例えば、企業内でのアカウント管理。普通に使っていると、AWSアカウントは1つではなく5個10個とドンドン増えてきます。それをどう管理すれば良いのか。開発環境や本番環境を、1つのアカウントで運用するのか、或いは環境ごとにアカウントをわければ良いのか。ケースバイケースで違うのですが、その考え方を書いています。
 つまりこの本は、普段業務としてAWSの導入支援する際にユーザーから相談されることをベースに、その1つの解になるように目指しています。対象とする範囲は、アカウント管理やIAMユーザー管理、社内システムとの連携をベースにしたネットワーク設計からセキュリティ・データ移行・運用と多岐に渡ります。企業にAWSを導入する際には、必ず参考になると思います。

Amazon Web Services 業務システム設計・移行ガイドの構成


 本書は、7章構成です。 ページ数も400ページ弱と、前2作に比べて、だいぶ薄めになっています。最初にAWSのサービスを紹介した上で、2章で本書で取り扱う内容の説明と指針をかいています。その後、3章以降で具体論を解説しています。わりと実用的な内容になっているのではと思います。

Chapter1 AWSサービスの概要
Chapter2 全体設計(管理方針と移行計画)
Chapter3 アカウント管理と権限付与
Chapter4 ネットワーク接続の設計・構築・維持管理
Chapter5 システム設計とサービスの導入
Chapter6 移行テクニック
Chapter7 運用監視の設計・実施

Amazon Web Services 業務システム設計・移行ガイドの執筆陣


 本書は、NRIグループの5人で書いています。林 晋一郎さんは、1冊目であるAmazon Web Services パターン別構築・運用ガイドの共著者で、NRIネットコムでAWS構築・運用の実務面の責任者です。何十というシステムの構築・運用を手掛けて来て、運用する自分自身が困らない設計・構築技法を身に着けています。6章の移行テクニックと、7章の運用監視の設計・実施を執筆しました。
 瀬戸島 敏宏さんは、野村総合研究所でAWSの実務面を取り仕切っています。Amazon Web Servicesクラウドデザインパターン設計ガイドの改訂版も執筆していました。また、NRI主催の各種ハッカソンやOne JAPANという企業横断プロジェクトのNRI代表などをしている多芸な人です。今回は、5章のシステム設計とサービスの導入を執筆しています。
 宮川 亮さんは、NRIグループのAWS周りのネットワークを一手に引き受けるスペシャリストです。NRIが提供するダイレクトコネクトサービスの設計・運用責任者として、通信キャリアやAWSと日々ハードネゴシエイトしています。開設したダイレクトコネクトの数は、おそらく日本有数だと思います。4章のネットワーク接続の設計・構築・維持管理を執筆しました。
 金澤 圭さんは、普段は大手B2C企業のAWSシステム構築を担当しています。最近はもっぱらサーバーレスアーキテクチャに傾倒していますが、今回は業務システムの話を書いてもらいました。何気に5人の中で、担当した部分が一番多いです。3章のアカウント管理と権限付与と、5章のシステム設計とサービスの導入を執筆しています。
 私(佐々木拓郎)の方は、全体的な構成と1章のAWSサービスの概要と2章の全体設計(管理方針と移行計画)を担当しています。

 著者陣に共通するのは、みんなAWSを使い倒しているということです。SIerの中の人と聞くと、手配師になってExcel方眼紙を触るだけの人と想像するかもしれません。しかし、そんなやり方をしないメンバーが集まって、この本を書き上げました。

まとめというか感想


 本書は、とにかく執筆に苦労しました。下のコミット履歴をみてみると、2月くらいから手掛けていて出版までほぼ一年掛かっています。理由としては、今まで執筆してきた中で一番業務に直結することなので、どこまで書けばよいのか逆に解りづらくなってしまったことにあります。また執筆は、業務時間外の平日夜間や休日に書くこともあり、本書の内容から土日も仕事をしているような感じでモチベーションが沸かなかったこともあります。まぁ凄いメンバーで何とか書ききれたので、私としては満足です。

f:id:dkfj:20171225092417p:plain

Amazon Web Services 業務システム設計・移行ガイド

Amazon Web Services 業務システム設計・移行ガイド

  • 作者: NRIネットコム株式会社:佐々木拓郎,林晋一郎,株式会社野村総合研究所:瀬戸島敏宏,宮川亮,金澤圭
  • 出版社/メーカー: SBクリエイティブ
  • 発売日: 2018/01/20
  • メディア: 単行本
  • この商品を含むブログを見る

目次編
Amazon Web Services 業務システム設計・移行ガイドの目次


See Also:
「この一冊で全部わかるWeb技術の基本」の監修をしました
「データを集める技術」という本を執筆しました
アプリケーションエンジニア向けのAWS本を書きました
『Amazon Web Services パターン別構築・運用ガイド』を書きました
『Rubyによるクローラー開発技法』を書きました

獺祭の適正価格に関する雑感

 もの凄く炎上しそうなので躊躇してますが、言いたいことが沢山あるのでつらつらと書いてみます。

日本酒と酒蔵を巡る現状


 まず予備知識として、日本酒を取り巻く状況を確認します。日本酒の国内出荷量のピークは1970年ごろで170万klで、現在はその1/3くらいの60万klまで減っている。造り手である酒蔵も減っていて、3,000以上あった酒蔵も今では1,400件程度になっています。この数字だけ見ていると、見事に市場は縮小しています。一方で興味深い数字もあります。特定名称酒とされる吟醸酒、純米酒の出荷量は堅調です。一番高い純米吟醸酒については、逆に増えています。
 ここの数字を見ていると色々と面白い物が見えてくるのですが、年間5,000kl以上の大規模生産者は15社あって、その15社が日本酒出荷の半分を担っています。そしてその生産の大半が、特定名称酒以外(≒安い酒)です。逆に規模が小さい生産者ほど特定名称酒の出荷割合が高いです。
 つまりは、小さい所ほど高級化路線の模索をしているのが垣間見れます。と言うより、生産量が少ないので付加価値高い物を売っていくしか生きていけないのでしょう。

f:id:dkfj:20171212003029p:plain

出典 
清酒製造業の概況(平成28年度調査分)日本酒をめぐる状況 - 農林水産省
清酒製造業者数の推移

獺祭の広告


広告の目的については、獺祭の旭酒造の社長インタビューの記事があるので、そちらをご参照ください。目的としては希望小売価格と取扱店を知らしめるという事のようです。キャッチーなコピーはどうかと思いますが、かなりの反響だったのでマーケティングとして成功なのではないでしょうか。

日本酒「獺祭」の蔵元、旭酒造が「高く買わないでください」と呼びかける新聞広告を掲載。広告に込めた思いを聞いた。

適正価格とは?


togetter.com

 この件で個人的にずっと引っかかってるのが、適正価格って何という話です。私は学生時代は経済学部だったので基本的には需要と供給が価格を決定するというシンプルな考え方が根底にあります。また、社会に出てから様々な商品の販売戦略、マーケティングを横で見てきて、価格を決めるという事の難しさも知っているつもりです。一方で個人的な体験として、買い手がいる価格に収斂していくという事も感じています。
 10年以上前にアメリカのグループ会社で働いていました。その時は結構暇だったので、eBayで買って日本のヤフオクで売るというせどり的な事を興味本位で幾つかの商品でやってました。その結果、商品の知名度(市場規模)で2つの傾向があることが解りました。知名度が高いものは、仕入れの価格帯もほぼ同じで常に商品がある代わりに、一定の手数料分をつけた値段でしか売れない。Fire Kingのマグカップやらポラロイドカメラがこのパターンです。Fire Kingはだいたい2,000円くらいで買ってヤフオクで4,000円くらいで売れるという感じです。倍で売れても送料やら手数料で利益は殆ど出ないです。買ってる方も、雑貨屋さんが仕入れとして買ってるケースが多く、店頭では8,000円くらいで売られていたようです。話を聞いてみると、手間を考えると別に儲かるものではないが、定期的に入荷する事でそれ目当てのお客さんが来るので入れているという感じのようでした。ちなみに知名度が低いものは必要とした人が探して買うと言うものが多く値段とはあまり関係なく売れました。
 話をFire Kingのマグカップに戻すと、元々は数百円だったものがアンティーク化されて一万円近い値段になった訳です。また、それぞれの工程で倍々の値段になっても売れます。結局、買う人がその値段に納得して買っているのであれば、何でも良いのじゃないと考えています。モラルの問題では無いと思います。もちろんお酒の場合は保存状態で品質劣化して造り手としては悩ましい問題なのは解ります。また、ニンテンドースイッチのように転売屋が買い占めるというのも望ましくないでしょう。ただ高くても良いから買いたいという人に、知恵と手間かけて商売している人がいても良いのではと思ってます。

ところ変われば値段も変わる



 少し話変わりますが、レストランでボトルのワインを注文した場合、小売店の店頭価格に対してどれくらいの価格差があるかご存知ですか?どのような店舗形態かによっても大きく変わりますが、一般的には3〜5倍という価格設定が多いです。つまり、レストランで3,000〜5,000円で売っているワインは、酒屋で1,000円のワインです。メニューで5,000円という値段をみるとかなりの高級ワインに感じるかもしれませんが、ごくごく一般的なワインです。で、この値段が高いと感じるか、安いと感じるか。単純にワインだけで考えると高く感じるでしょうが、店側の言い分としては買い付けや保管料、サーブするサービス料、そもそもの店舗の運営費を載せた金額になっています。また、料理とあわせる付加価値という面もあります。
 あるいは、アメリカの寿司屋では、十四代とか一本あたり恐らく2〜3万円の価格設定で出されていました。高いところだと、10万円近いところもあったんじゃないかなと思います。それでも、日本酒好きなアメリカ人はこれが旨いんだよといって喜んで飲んでいました。逆に、現地のスーパーで1,000円くらいで売ってたワインが、日本の小売店だと2,000〜3,000円くらいというのもザラにあります。ところ変われば値段も変わるのです。獺祭を高値で売っているお店も、売れる値段で売っているのです。

売り手は、売ってしまった商品に対しては願望を伝えることしか出来ない。



 そもそも売ってしまった後には、売り手ができることって殆どないのですよね。今回の広告も、それがよく解っているので、お願いという形になっているんでしょう。私も、何冊か本書いていて或いはアプリとか出したことがあって、受けてがどう受け取るかで非常にやるせない思いをすることもありあmす。

 例えば、Amazonのレビューで★1のやつ。

内容はOK、Kindle版のデータ形式はクソ

 それは著者の私でもどうしようも出来ないのだよと強く主張したいのですが、買い手としては総体としてのサービスなので上記のようなサービスになります。これに対して怒ってもどうしようもないです。或いは、想定の読者層と違う人がよんで、難しすぎるとか初歩的すぎるとか。言いたいことも色々でてきますが、甘んじて受け止めるしかないのです。

そもそも日本酒って安すぎない



 どうでもよい愚痴をつらつら書いていましたが、もうひとつ。ワインを普段飲んでいる身としては、日本酒って相対的に安いなと感じています。もちろん輸入しているものと、生産国で買っているという違いがあるものの、同じ価格帯で比べると日本酒の方がクオリティ高いものが多いように感じます。また、上限もせいぜい数万円くらいです。もっと10万、20万するような日本酒が出ても良いのではないでしょうか?そういう意味で、ブランド戦略が非常に上手くいっている獺祭については、もう少し強気な価格設定したほうが良いんじゃないのと思っておりました。
 Twitterで教えてもらったのですが、元サッカー選手の中田さんが海外で高級路線の日本酒を出しているようです。このような取り組み、国内国外問わずにもっとあっても良いのではないかなと思います。

forbesjapan.com

どんな日本酒が好きなの?



 最近はそれほど飲んでいないのですが、私は日本酒も結構好きです。大吟醸のようなスッキリしたものではなく、純米のような雑味が多いものが好きですね。冬はぬる燗くらいでちょっと温めたくらいが良いですね。銘柄は特定のこれというのは無いですが、七本槍とか而今とか好きでしたね。(而今も今は、プレミア酒になっているとか)

f:id:dkfj:20171212122228j:plain

まとめ



 需給だけで考える奴は馬鹿だろという反応に対して、何考えているかを書き出してみた次第でございます。しかし、別に当事者ではないので、これ以上特に思うところはありません。一方で、酒蔵やっていた親類が5年ほど前に廃業していて、もったいないなぁという思いはずっとあります。

コンテナ化とサーバーレス、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版
  • この商品を含むブログを見る