プログラマでありたい

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

Amazon Web Services 業務システム設計・移行ガイドのKindle版でました!!

 本日発売開始のAmazon Web Services 業務システム設計・移行ガイドですが、同時にKindle版も出ました。

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

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

  • 作者: 佐々木拓郎,林晋一郎,瀬戸島敏宏,宮川亮,金澤圭
  • 出版社/メーカー: SBクリエイティブ
  • 発売日: 2018/01/20
  • メディア: Kindle版
  • この商品を含むブログを見る

 残念ながら、全ページ画像の「固定レイアウト型」となっています。その為、ピンチイン・ピンチアウトなどの文字拡大や、ハイライトとかは付けられてません。著者としても何とかして欲しいところですが、技術書の市場規模を考えると余りコスト掛けられないという事情も解ります。版組の技術革新で何とかできないものですかね。

Amazon Web Services 業務システム設計・移行ガイドの電子立ち読み版


 税込みで3,456円とそれなりのお値段となっております。興味だけで買ってみるのはお財布に痛いと思います。今回は何故か、電子立ち読み版というのが出ています。最初の1章まるごと読めますので、内容が気になる方は是非読んでみてください。ただ1章については、サービス紹介など一般的な内容を載せざるをえなかったので、本書の特徴が出て来るのは2章以降です。何とか2章も載せてほしかったと思います。

r.binb.jp

Kindle版のメリット


 Kindle版は、かさばらないとか、持ち運びが便利などのメリットがあります。実はそれ以外にもあまり知られていないメリットがあります。本は改訂時に大幅に修正されます。また、増刷時にも細かい修正がされることが多いです。Kindle版であれば、一度購入すると無料で最新版を手に入れることができます。技術書の場合、これが嬉しいです。そんな訳で、私はもっぱら技術書もKindleで購入しています。もちろん紙の読みやすさは、まだまだ捨てがたいものあります。ぜひ、自分のスタイルにあったものをお選びください。


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

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

  • 作者: 佐々木拓郎,林晋一郎,瀬戸島敏宏,宮川亮,金澤圭
  • 出版社/メーカー: SBクリエイティブ
  • 発売日: 2018/01/20
  • メディア: Kindle版
  • この商品を含むブログを見る

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

複数のAWSアカウント管理を制するものが、AWSを制する

 いよいよ明日発売開始であるAmazon Web Services 業務システム設計・移行ガイドの一貫したテーマが、「企業内でどのようにAWSを使っていくのか」です。企業内でのユースケースを元に、ネットワーク/システム設計や運用管理、移行の話をしています。その中で1章を割いて説明しているのが、AWSアカウントをどのように管理するかです。

複数(マルチ)AWSアカウント管理の重要性


 AWSを利用する上で、AWSアカウントをどのように管理していくかは最重要事項です。AWSアカウント管理というと、一般的には、AWSリソースの認証認可であるIAMを使った運用方法について語られることが多いです。しかし、企業内で利用する際は、それだけでは不十分です。何故なら、企業内では1つのAWSアカウントではなく、複数のAWSアカウントを作成し運用することになるからです。いわゆるマルチアカウント運用です。
 企業内での運用がマルチAWSアカウントとなる理由は、主に管理上のメリットです。現状のIAMの機能では、サービス単位の管理が基本となります。リソース単位の権限管理も可能ですが、安全簡単に設定できるという構造にはなっていません。例えば、EC2のインスタンス管理について考えてみましょう。開発者と運用者というロールがあるとして、開発環境は開発者が管理し、本番環境は運用者が管理するとします。この場合、開発者は本番環境のインスタンスの操作はできないようにしないといけません。現状のIAMの機能では、これを実現するにはIAMの設定中に具体的なりソース名(インスタンスID)を列挙していくしかありません。また、インスタンスの一覧から権限がないものについて見えなくするというようなことも出来ません。
 現実的にはIAMのみでの運用は難しいので、本番環境用のAWSアカウントと開発環境用のAWSアカウントを分離することになります。これがマルチアカウント化の第一歩です。次に組織別のAWSアカウントです。一定以上の規模であれば、複数のサービス・プロジェクトを運用していることでしょう。また企業内の組織構造も、そのミッションに従って本部/部/室などの単位で別れていると思います。ここで、AWSのアカウントを組織横断で運用できるかという問題がでてきます。横串にAWSアカウントを管理するような組織があれば可能かもしれませんが、現実的には余り実現していません。
 結果的に、AWSアカウントは組織ごと環境ごと作成されることになります。つまり1つの企業内にAWSアカウントが10も20もあるというのが当たり前の状況なのです。これを何も考えずに放置していると、それぞれの組織毎に同じようなことに頭を悩ませ、試行錯誤することになります。それを回避するには、最初に下記のようなことを考える必要があります。

・AWSのアカウント管理方法
・AWSアカウントをどの単位で分割するべきか
・IAMの権限付与設計

 こんなようなことを考えていくのがアカウント管理設計ですね。

f:id:dkfj:20180119072331p:plain

AWSのアカウント管理方法 には、AWS Organizations


 現状のAWSの機能でいうとAWSのアカウント管理には、AWS Organizationsを使うことになります。これは名前の通り、組織内で利用するAWSアカウントを管理する為の機能が提供されています。AWS Organizationsを使うことにより、アカウントのグループ化であったり、アカウントで利用できる機能の制限することができます。また、このサービスについては従来の一括決済機能の発展的な部分があり、請求を一つにまとめるということができます。概念図としては、次のような形になっています。

f:id:dkfj:20180119072307p:plain

 このAWS Organizationsについて、どう使っていくのか明確な指針を出せている所は少ないと思います。例えば、サービスコントロールには、ブラックリスト方式とホワイトリスト方式の2種類があります。また、制限をかける範囲をrootからにするか、Organization Unit単位にするかなどの選択肢があります。この辺りについて、Amazon Web Services 業務システム設計・移行ガイドの3章で重点的に解説しています。

マルチアカウント化したものの


 一方でマルチアカウント化したら、それで全て解決かというとそうでは無いのですよね。例えば、ネットワーク接続をどうするかなどの問題があります。2017年末にDirect Connect Gatewayが出て、専用線を使った複数VPCの接続方法が柔軟にできるようになりました。ただし、現状では別アカウントのVPCを接続できません。或いは、AWS Systems Managerという機能がでてEC2やRDSをグルーピング化できるようになりました。これで権限管理も出来ないかなぁとか色々思うところもあります。
 組織が違えば運用形態も違うので、ただひとつの正解というのは無いと思います。その中で、比較的ベスト・プラクティスに近いのを集めて行ければなぁと思っています。ということで、Amazon Web Services 業務システム設計・移行ガイドは明日発売です!!

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

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

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

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

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 業務システム設計・移行ガイド (Informatics&IDEA)

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

  • 作者: 佐々木拓郎,林晋一郎,瀬戸島敏宏,宮川亮,金澤圭
  • 出版社/メーカー: 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によるクローラー開発技法』を書きました