技術者であることを諦めない - プログラマでありたい
だいぶ前にAWSのAmbassadorが集まっての懇親会がありました。年齢の話になって聞いていると、どうやら私が最年長グループでした。最年長！！おっさんです。私は42歳で、役割的な部分を考えれば、そうなるのも無理はないのかなという気がします。せっかくなので、ポエムっぽいブログエントリーを残しておきます。 SIerの中での技術者の生き方 技術者と書くのがよいのか、ITエンジニアと書くのがよいのかイマイチ解りませんが、ここでの技術者は、下記のように定義しておきます ※あくまでこの文脈の中だけの定義です。 主たる業務に対して、自身のもつITの技能・知識を持って業務を遂行している 業務で必要とされる技術の変化に追随しつづけている ここで重要なのが2つ目の技術の変化に対して追随し続けるという点です。一口にSIerといっても対象とする業種や業態によって必要とする技術は大きく違います。業務知識がとにかく
AWSのEBS Provisioned IOPSからEBSについて妄想する - プログラマでありたい
以前、EBSの内部構造を調べていて「結構知らないAmazon EBSの細かい話。主にEBSのネットワークの構造について」という記事を書きました。そこでEBSの性能はネットワークの帯域で制約される旨を書きました。すると、@namikawaさんに次のような指摘を頂きました。 このsh2さんのブログにも書いてあるけど、QEMUなりcgroupのレイヤでの制限に近いやり方なのかなぁと思っています。ただの想像ではありますが。d.hatena.ne.jp/sh2/20121217 確かにネットワークが性能の制約にはなりうるけど、ネットワークだけではProvisioned IOPSのようなIOPS単位での性能の制御は出来ないなぁと疑問に思っていました。気になったので、EBS絡みの性能測定や考察・Tipsを読んでみましたが、まだまだ解らない所だらけです。それでも、今回得た情報を元にProvisioned
周回遅れで、SSDベースの新しいAmazon EBSの話 - プログラマでありたい
少し前ですが、AWSのサービスに重大なアップデートがありました。ストレージサービスであるEBSに新しいサービスラインナップが追加され、General PurposeというSSDベースのサービスが利用できるようになりました。すでにyoshidashingoさんが色々考察しているので改めてまとめる必要もないですが、自分の中の整理のためにまとめてみます。 EBSのラインナップと価格体系 2014/06～ 今回追加されたのは、General Purpose(gp2)です。従来のスタンダードEBSはMagneticという名前になり、Provisioned IOPSは、io1という略称になりました。 東京リージョンで利用例 サービス名 ベースラインIOPS Max IOPS 価格体系 General Purpose (SSD) 3(IOPS)×GB 3,000(burst) $0.12 1 か月にプロ
結構知らないAmazon EBSの細かい話。主にEBSのネットワークの構造について - プログラマでありたい
先日、EBS（Elastic Block Store）のとある状況下での挙動について正確なところが知りたくて、改めて調べていました。その中で、AWSマイスターシリーズ ReloadedのEBS版を見つけたのですが、これが良い資料でした。今までEBSのネットワーク部分についてどういう構造になっているのか、正確に把握しませんでした。資料を読むことにより構造が解り、ボトルネックが発生した時にどう対処すればよいのか、より掴みやすくなりました。簡単にまとめてみたいと思います。 EBSの全体像 まずはEBSの基本構造です。当たり前といえば当たり前ですが、EBSはEC2ではなくその下のレイヤーのハイパーバイザにアタッチされます。アタッチ後にOSから認識させるという形になります。また接続の方式としてはネットワーク型ですが、利用者はネットワークを全く意識せずとも使えるようになっています。（SecurityG
AWSのAZの割り当ては、アカウントごとに違うという話 - プログラマでありたい
先週の金曜日（2019/8/23）に発生したAWSの東京リージョンで大規模な障害が発生しました。障害の内容は、一つのAZで空調設備の問題からEC2インスタンス並びにEBSに問題が発生したという事象です。詳細についてはAWSから発表があるので、そちらをご参照ください。 aws.amazon.com 障害の最中にTwitterのタイムラインを見ていると、単一AZ障害ではなく複数のAZで障害が発生しているのではないかという観測が多く見られました。障害としては、AWSの発表通り単一AZ障害です。では何故多くの人に勘違いされたのでしょうか？理由は2つあります。 AZの割り当ては、アカウントごとに違うという事が知られていない マルチAZ構成にしていても、単一AZの障害の影響を受ける ここでは前者のAWSアカウントの割り当ての話を説明します。 あなたが見ているap-northeast-1aは、私が見てい
マルチ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の名前解決で実現している点です。このアーキテクチャは私の個人的な予想ですが
Amazon Elastic Load Balancing (ELB)の内部構造および拡張・障害時の動き - プログラマでありたい
諸般の理由により、AWSの各サービスの挙動を改めて復習中です。まずは、Amazon Elastic Load Balancing 、通称ELBについてです。ELBの内部の動作については、公開されている公式ドキュメントが割とあります。是非一度しっかりと目を通しておくとよいですよ。少なくともAWSマイスターシリーズのELBについては、読んでおくべきです。簡潔にかつ詳しく説明されているので、理解が格段に進むでしょう。というところで、現段階で私が理解しているELBのアーキテクチャをまとめてみました。 ELBの内部構造 ELBは、ELBエンドポイントとELBインスタンス（仮称）によって構成されます。ELBインスタンス（仮称）の正式名称は知らないので、その名前で呼ぶことにします。ELBインスタンスには、グローバルIPが付与されます。ELBエンドポイントは、myLB-xxx.elb.amazonaws.
AWSの新サービス群に対する一行所感 - プログラマでありたい
今年もラスベガスで、AWSの最大のイベントre:Invent開催中です。初回のキーノートが終わった所ですが、怒涛のサービス発表で頭が混乱中です。整理のために、サービスに対する感想をつけてみます。間違っているかもしれないので、悪しからず。 AWS AppSync モバイル等での複数端末のデータ同期を見据えたソリューション。必要性はすごく解るが、それってCognito Syncでやりたかったことじゃないのかな？認証認可のサービスにデータ同期を加えた筋の悪さを解消に来たのか？ 2017/12/3 追記 中の人曰く、次のような役割分担とのこと AWSの新サービス群に対する一行所感 - プログラマでありたい ありがたし / Cognito Syncは「一つのIdentityに（≒一人の人間）が持つ」複数端末間での設定値等の同期のためのものだったので、前提と志向が違うのです > AppSync “それ
本を書く前に準備したこと、執筆中にしていたこと - プログラマでありたい
「Rubyによるクローラー開発技法」は、2013年12月に話を頂き、2月くらいまで企画を検討し、2月〜7月の約5ヶ月間で執筆しました。役に立つかどうか解らないけど、本を書く前に準備したことと、執筆中にしたことを残していこうと思います。次回があれば、もう少し上手くできるようにしたいですね。 事前に準備したこと 執筆環境を構築した 執筆環境は、いの一番で用意しました。具体的には、下記の2つです。 GitHubの有料版アカウントを作成し、プライベートリポジトリを作った MarkDown記法を覚えて、MarkDownから各種フォーマットに変換できる環境を作った GitHubのプライベートリポジトリを作ったのは正解でした。これが無ければ、いろいろ事故も起こったと思います。反面、Markdownの環境はメインのMacにしか作らなかったのが失敗でした。意外に色々な端末で書くことになったので、CIツールも
クローラーとAWSが出会ったら？第3回Webスクレイピング勉強会@東京 - プログラマでありたい
2014/10/26に開催された第3回Webスクレイピング勉強会@東京に参加して、発表してきました。今回は、スクレイピングと少し離れてAWSを使ってクローリングするという話です。クローラー／スクレイピングとAWSは相性が良いというのは、昔から思っていたのでテーマとして扱うことは早めに決めていました。しかし、話の構成を、具体的なテクニックの話にするか、概念的な話にするか、少し悩みました。なるべき多くの人に伝わるように、概念的な話をしたつもりです。具体的な部分についてはRubyによるクローラー開発技法を読んで頂ければと思いますw 発表資料 Scraping withawsAWSを利用してスクレイピングの悩みを解決するチップス from Takuro Sasaki Scraping withawsAWSを利用してスクレイピングの悩みを解決するチップス 資料の構成としては、クローリングする際の悩み
クローラー／スクレイピングのWebサービス 「Kimono」のユースケース - プログラマでありたい
クローラー／スクレイピング Advent Calendar 2014の8日目です。あと、全部俺Advent Calendarも開催中です。 クローラー/スクレイピングをするのであれば、是非知っておいて欲しいサービスが「Kimono」です。Kimonoは、KimonoLabsという会社が作ったクローラー/スクレイピングを行うWebサービスです。特徴としては、プラグインを入れてブラウザの操作のみでスクレイピングができることです。操作を覚えれば、ITエンジニアでなくても充分使いこなせると思います。 Kimonoの使い方については、プログラミング・レスで5分でサックリWebスクレイピング「kimonolabs」というエントリーで紹介しています。今回は取得したデータの利用方法とユースケースを考えてみたいと思います。 Kimonoで収集したデータの利用方法 Kimonoで収集したデータは、API経由で
何故JSONPでJavaScriptのクロスドメイン通信ができるのか？ - プログラマでありたい
一人Advent Calendarの3日目です。 JSONPを使って外部のAPIを呼び出して、結果を取り込むということは色々なところで行われています。しかし、そもそもJavaScriptを利用した場合、クロスドメイン通信が使えないという前提があります。JSONPだったら、何故そこを回避できるのでしょうか？あまり詳しく考えたことが無かったので、簡単に調べてまとめてみました。なんというか4周くらい遅れている話題ですが、気がついた時に整理するとスッキリします。 JSONPの動作原理 Wikipediaさんをみてみると、そのものずばりのことが書かれています。scriptタグ内のsrc属性は別ドメインのURLを指定できるという点と、そのレスポンスはJavaScript関数呼び出し形式になるという点をついたのが、JSONPの動作原理です。なんというか、仕様の考慮不足を利用した仕組みだと思います。 JS
運用視点でChef ServerかChef Solo + Knife Soloのどちらが良いか考えてみた - プログラマでありたい
ChefとFabric、どちらが良いか悩んでいるうちに、Chefが一気にブレイクしてしまった今日この頃です。と言うことで、Chefを中心に今後のサーバ構築・運用について考え中です。そこでまず出てくる問題が、Chef Server+ClientとChef Solo + Knife Solo、どちらの構成が運用しやすいかという点です。 状況を整理する為に、まずは簡単にChef Server, Chef Solo, Knife Soloの関係や役割をまとめて見ます。 Chef Server サーバーの状態を管理し、それに関する情報を保持しておくのがChef Serverです。Client側は個々のサーバにインストールされて、Chef Serverに司令を問い合わせて実行します。Chef ServerはDBやキューなどを持ち、少し複雑な構造です。同じカテゴリーの製品として、PuppetやFabri
JenkinsとSelenium WebDriverでUI層のテストも自動化＆永続化する - プログラマでありたい
思い立ったようにJenkins特集をしておりますが、今回はJenkinsとSelenium WebDriverでUI層のテストの自動化をする話です。Seleniumは面倒臭い画面のテストを自動実行してくれるツールで、出てきてからもう７〜８年がたちます。Web系の開発に携わっている人であれば、一度は試したことがあるのではないでしょうか？そして、必ず挫折したことがあると思います。 その理由としては、せっかく作ったSeleniumのテストケースが腐ってくるからです。一般的にはUI層の変更は、ロジック層に比べて変化が激しいです。だからこそテスト自動化して保証することに意味があるのですが、そのテストケースを維持するのは大変です。そこで、Jenkinsの登場です。Jenkinsでサーバサイドで継続的に実行することにより、Seleniumのテストケースが成功を保てるようにします。また、複数のブラウザ・バ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
