マルチAZ構成で単一AZの障害の影響を受けるのは何故か？ - プログラマでありたい
昨日の「AWSのAZの割り当ては、アカウントごとに違うという話」で宿題として残した、マルチAZ構成で単一AZの障害の影響を受けるのは何故かという問題について考えてみます。キーワードはELBです。 前提としてのELBの実装（の予想） マルチAZ構成での障害発生原因を検討する前に、まずELBの実装について考えてみましょう。5年ほど前に書いたELBの挙動からみる内部構造の推測です。 blog.takuros.net 旧ELB（CLB）をもとに書いていますが、ALBでも大きく変わらないと思います。要点としては、ELB自体は、AWSが管理するEC2インスタンス上で稼働し、バランシング先のAZにそれぞれ配置されているということです。図ではELBインスタンス（仮称）として表しています。そして、ELBインスタンスへの振り分けはDNSの名前解決で実現している点です。このアーキテクチャは私の個人的な予想ですが
「データを集める技術」という本を執筆しました - プログラマでありたい
Webからデータを集めるというテーマで、「データを集める技術」という本を書きました。中身は、クローラー／スクレイピング本なのですが、それだと内容が「Rubyによるクローラー開発技法」と丸かぶりになってしまうので、本職プログラマでない人でも読めるような内容を目指して書いています。 データを集める技術 最速で作るスクレイピング&クローラー 作者: 佐々木拓郎出版社/メーカー: SBクリエイティブ発売日: 2016/11/29メディア: 単行本この商品を含むブログを見る Excelでデータ収集をする理由 メインのターゲットは、ITエンジニアです。ただし前述のとおり、プログラマでない人でも何とかなるように目指しています。ということで、メインのデータ収集環境は、ExcelとGoogleスプレッドシートです。何故、Excelを選んだかというと、技術書で10万冊売れるのはExcelだけだから。環境構築の
上級者向けの技術書が少ない理由 - プログラマでありたい
AWS本やクローラー本を出していると、「上級者向けの本は出さないのですか」とよく聞かれるます。残念ながら日本のIT業界向けの出版事情を考えると、なかなか難しいというのが正直なところです。 IT業界向け出版物の市場規模 難しい理由として、市場規模があります。IT業界で働く人の数は定義次第なので幅がありますが、100万人程度と仮定します。市場の規模は、この母数に対して1人あたり何冊買うかが上限となります。この段階で、コミックや一般書に較べて、著しく小さいことが解ると思います。 さらに初級・中級・上級とカテゴライズすると、この母数に対して更にフィルタリングすることになります。コミックだと対象年齢はある程度はあるものの、レベルによってフィルタリングすることはないですね。市場規模は下の概念図のとおり、上級者の市場は必ず初級・中級者の市場より小さくなります。 細分化されたカテゴリ この段階で上級者向け
スクレイピングのお仕事について - プログラマでありたい
今年一番のトピックスは、クローラー本の出版でした。ちょうど、昨年の今頃に企画が舞い込んできて、2月〜7月くらいでせっせと書いていました。企画から執筆中まで、一貫してクローラー本の需要があるのか半信半疑でした。半信半疑というより、売れないだろうと思いながら書いていました。しかし、蓋を開けてみたら思いのほか好調で、既に増刷も2回繰り返しています。Amazonの順位の方も順調で、4ヶ月程ほぼ3,000位以内をキープしています。 これが不思議で仕方がないので、どんな人がクローラーやスクレイピングを必要としているのか、ちょっと考えてみます。考える材料としては、クラウドソーシングサイトで「スクレイピング」や「クローラー」、「データ収集」といったキーワードで検索してみます。対象のサイトとしては、以下の2サイトです。 Lancers CrowdWorks クラウドソーシングでの求人の分類 人間系の収集＆ま
作って覚える転置インデックス、「検索エンジン自作入門」 - プログラマでありたい
先行発売で、検索エンジン自作入門を購入しました。まだペラペラと眺めている状況ですが、これが非常に面白いです。 「検索エンジン自作入門」は、集めた文章をいかに整理するかをテーマとして扱っている本です。整理するという意味は、検索エンジンを利用するというライフハック的な意味ではありません。整理する為の検索エンジン自体を自分で作ることで理解するという、極めて硬派な本です。 「検索エンジン自作入門」とは？ 「検索エンジン自作入門」は、未踏IT人材発掘・育成事業にスーパークリエータに認定された山田浩之氏と、Senna/groongaの開発者の末永匡氏の共著です。検索エンジンについて語らせたら、日本でこれ以上の人たちはいないだろうという組み合わせです。ということで、内容は非常に濃いのですが、難しい内容を解りやすく解説されています。 一方で、扱っている内容は非常にマニアックです。下に目次付けておくので見て
KimonoLabsと今後のサービスのあり方のはなし - プログラマでありたい
別記事にも書きましたが、第2回Webスクレイピング勉強会@東京に参加してきました。そこで注目のサービスであるKimonoLabの中の人であるPratap Ranadさんの話を聞いてきました。シンプルながら明確なメッセージで、非常に感銘を受けました。 KimonoLabsのミッション KimonoLabsの始まりは、あるサービスを作ろうとして航空会社ごとのデータを取得しようとしたことが始まりのようです。しかし、航空会社ごとにWebスクレイピングするのは手間で、非常に大変だったそうです。サイト側がAPIを提供すれば解決なのですが、APIを提供している会社は0.0005%に過ぎないそうです。またセマンティックWebにすれば良いという話もありますが、あれはデータを提供する側が努力する必要があり、そもそも構造として間違っていたとのことです。KimonoLabsはこの構造を逆転させ、データを取得する方
何故、fluentdなのか？ - プログラマでありたい
最近、fluentdという言葉を聞くことが多いと思います。fluentdは、それぞれのサーバからログを収集し集約する為のアプリケーションです。fluentdは「Log everything in JSON」を合言葉に、全てのログをJSON形式で扱います。また一緒に聞くキーワードとしては、大規模とかリアルタイムとかがあると思います。この時点で関係ないやと思って、興味を失った人も多いと思います。しかし、今後のログ管理は、fluentdが主流になるか解りませんが、同様の集約するフレームワークが中心になると思います。 何故、fluentdが必要か？ まずはオンプレミスの世界から見て行きましょう。ログはサーバーにたまり、管理者はサーバにログインしてログを参照します。特に問題はありません。 次にAutoScalingを使わないAWSの世界です。これも同様に、ログはサーバーにたまり、管理者はサーバにログ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
