タグ

ブックマーク / blog.takuros.net (115)

  • 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

    AWSのEBS Provisioned IOPSからEBSについて妄想する - プログラマでありたい
  • AutoScalingのインスタンスをどう扱うのか(デプロイ編) - プログラマでありたい

    AWS Advent Calendar 2013 の 5日目 のエントリーです。ついでに独りでAdvent Calendarに挑戦中です。 みんな大好きAutoScalingの話です。AWSのAutoScalingは負荷に応じてサーバ(EC2)を自動的に縮小・拡張することが出来る夢のようなサービスです。AutoScalingを上手く活用出来れば、急なアクセス増でサーバが耐え切れずSorryページを出すという残念な結果を防げます。実際に使っていて、ピークに合わせて自動的にサーバが増えて徐々にサーバが減っていく様子をグラフで見ると、AWS使ってて良かったなぁとしみじみと実感できます。 しかし、JAWSUGなどでAWSを使い始めた人にAutoScalingを使っていると聞いても、使いたいのだけどまだ導入出来ていないという返事が多いです。何故でしょうか?幾つかパターンがありましたので、整理してみま

    AutoScalingのインスタンスをどう扱うのか(デプロイ編) - プログラマでありたい
  • スマホ版ドラクエ1にみる20年後のゲーム業界の可能性 - プログラマでありたい

    スマホ版のドラクエ1をダウンロードして、通勤の傍らせっせとレベルアップしてLv30まで上げてからクリアしました。ローラ姫は助けていません。 さて題です。ドラクエしてて思い出したのですが、子供の頃に親に一緒にファミコンをしようと誘っても全然やりませんでした。その当時は大人になったらゲームは面白く無くなるのか程度にかんがえていました。それから20年以上が経ち結婚もして子供も生まれ当時の親の年齢に近づいてきて解ったのですが、幾つになってもゲームは面白いです。時間がないのでやりませんが、状況が許すのであれば幾らでもできます。たぶんドラクエシリーズ全部やって、全部レベルMaxにするくらいは出来る自信があります。そんな理由からソーシャル・ゲームは、人生狂わす程にハマる恐れがあるので近づかないようにしています。ということで大人になっても、充分ゲームは楽しめます。 とすると、私の親は何故ゲームをしなかっ

    スマホ版ドラクエ1にみる20年後のゲーム業界の可能性 - プログラマでありたい
  • Amazon WorkSpacesについて。或いは「JAWS-UG Osaka 特別編 re:Invent 2013 報告会」参加レポート - プログラマでありたい

    遅くなりましたが、11/29に行われた「JAWS-UG Osaka 特別編 re:Invent 2013 報告会」の出席レポートです。他の参加者や登壇者の金春さんも書いておられるので、一番興味があったWorkSpacesの部分だけまとめます。参加レポートと私の感想が入り混じっていますので、ご注意ください。 Amazon WorkSpacesのサービス概要 Amazon WorkSpacesは、AWSのリソースを使ったVDIサービスです。サーバ側のみならず、クラウドを利用してクライアント側の問題を解決するということで、Amazonとしても力を入れようとしているサービスの1つのようです。その証拠に、Amazonの矢印付きのロゴをサービスロゴに入れているとのことです。一方で、Amazonの日側としては、困った問題があるようです。サービス名がWorkSpacesと複数名表記なので、日語の表記を

    Amazon WorkSpacesについて。或いは「JAWS-UG Osaka 特別編 re:Invent 2013 報告会」参加レポート - プログラマでありたい
  • Immutable InfrastructureとChefと冪等性の話 - プログラマでありたい

    最近話題になっているImmutable Infrastructure(イミュータブル・インフラストラクチャ/サーバ)。あんまりよく解っていないので、整理してみました。 Immutable Infrastructureとは? そもそもImmutable Infrastructureとは、何でしょう?極論すると、「稼働中のサーバの構成管理をやめて、サーバを使い捨てにしよう」という考え方です。これだけ言われても、さっぱり解らないと思います。 まずは従来の考え方。Mutable Infrastructureというのか、既存のサーバに変更を加えていくことが前提になります。 それに対して、Immutable Infrastructure。直訳すると変化しないインフラとなります。どういうことかと言うと、サーバ構成(ミドル・アプリ)を変更したい場合は新規にサーバを立ちあげ、そこに既存の機能と新規の機能を加

    Immutable InfrastructureとChefと冪等性の話 - プログラマでありたい
  • 結構知らないAmazon EBSの細かい話。主にEBSのネットワークの構造について - プログラマでありたい

    先日、EBS(Elastic Block Store)のとある状況下での挙動について正確なところが知りたくて、改めて調べていました。その中で、AWSマイスターシリーズ ReloadedのEBS版を見つけたのですが、これが良い資料でした。今までEBSのネットワーク部分についてどういう構造になっているのか、正確に把握しませんでした。資料を読むことにより構造が解り、ボトルネックが発生した時にどう対処すればよいのか、より掴みやすくなりました。簡単にまとめてみたいと思います。 EBSの全体像 まずはEBSの基構造です。当たり前といえば当たり前ですが、EBSはEC2ではなくその下のレイヤーのハイパーバイザにアタッチされます。アタッチ後にOSから認識させるという形になります。また接続の方式としてはネットワーク型ですが、利用者はネットワークを全く意識せずとも使えるようになっています。(SecurityG

    結構知らないAmazon EBSの細かい話。主にEBSのネットワークの構造について - プログラマでありたい
  • はてなブックマークとSEOと検索エンジンと@fladdictさん - プログラマでありたい

    体調わる子さんのブログのアクセス数とAmazonアフィリエイトの結果を見て、割りと驚愕を受けました。50万PVで6千円台とのことで、恐ろしく効率が悪いなぁと。 一方で、はてブの傾向を考えると納得いく部分もあります。はてブ経由のアクセスは、ハッキリ言って殆ど収益性はないのです。以前、はてブ1万ブックマークの顛末で軽く触れましたが、トップに載って数万アクセスを得ても全く物は買ってくれません。当に買ってくれません。ブコメの欲しいってなんだよと思うくらい買ってくれません。儲かってるんだろうなぁと羨ましがる必要が無いほど、買ってくれません。同様にGoogle Adsenseのクリック率も低いです。はてなの経営が大丈夫かと思う程、広告は踏まれません。それほどに訓練されているのが、はてなブックマークユーザです。 では、収益性が高いページというのは、どういったページなのでしょうか?それは、検索経由でア

    はてなブックマークとSEOと検索エンジンと@fladdictさん - プログラマでありたい
  • AWSのEC2でAmazon Linux AMIを使うかどうか? - プログラマでありたい

    最近、微妙に気になっているテーマがあります。EC2でインスタンスを使う際に、Amazon Linux AMIを使うかどうかという点です。何を言っているのだ、お前というような悩みなので背景を簡単に書いておきます。 Amazon Linux AMIを使わないようにしようかなと思った理由 そもそものキッカケは、Chefを使うようになったことです。Chefで環境をコードで記述するようになると、ローカルの開発環境であろうが、検証・番環境でも基的にはコマンド1つで構築できます。しかし、気が付いてしまいました。ローカルの開発環境に、Amazon Linuxをインストール出来ないことに。このことはChefを使い出すと同時に、VirtualBox+Vagrantを使いだしたことで顕著に感じるようになりました。 また私の所属しているチームの特性上、様々なプロジェクトに関与してプラットフォームもAWSだけで

    AWSのEC2でAmazon Linux AMIを使うかどうか? - プログラマでありたい
  • 1万ブックマークを達成して気がついた3つのポイント。或いはソーシャル・ネットワークについて - プログラマでありたい

    はてなダイアリーを始めて、早6〜7年です。先日、1万ブックマークを達成しましたので、備忘録がてらに記録を残しておきます。1万ブックマークを意識したのは、今年の4月です。例のはてなのブックマークアルゴリズムの変更もあって、ホットエントリーに載るのはそれ程難しくないなぁという状況に気が付きました。当時、4,800ブックマーク程あったので、月600超ブックマーク平均で8ヶ月続ければ年内に達成出来るなと算段しました。月10〜15エントリー書くとして、平均40〜60くらい。1つ2つ当たりが出れば100〜200は簡単に行くので、2エントリーで300と残りの10エントリーで300と考えていました。結果的には、ほぼそれに沿う形で前倒しで達成出来ました。 そんな中で、ブックマークされるエントリーを考えながら8ヶ月を過ごして、幾つか気がついたことがあります。まとめてしまうと、これまた身も蓋も無い内容になってし

    1万ブックマークを達成して気がついた3つのポイント。或いはソーシャル・ネットワークについて - プログラマでありたい
  • 社会人なら知っておきたいお金にかかわる3つの話 - プログラマでありたい

    最近はそうでもないですが、何故か日ではお金について語るのは卑しいという風潮があります。そのせいかも知れませんが、学校でお金に関わる教育というのは殆どありません。私は経済学部を卒業しましたが、国家・企業のファイナンスの話は学びましたが、個人の財産形成という話はとんと聞いたことがありません。その結果、割と投資とか資産形成とは全く無縁のままの人や、銀行や証券・保険会社に勧められるがまま従っているという人も多々います。ということで、これだけは知っておきたいという3つのポイントです。 『投資お金持ちがするもの』では無い 複利の魔力 お金を貯める時は、給与天引き or 自動引き落とし 『投資お金持ちがするもの』では無い まず知っておかないといけないことは、投資お金持ちだけがするものではないということです。一番大事なのが、この1点です。投資の話になると「投資に回すようなお金がない」とか、「そんな

    社会人なら知っておきたいお金にかかわる3つの話 - プログラマでありたい
  • 周回遅れでGmailのカテゴリーとスパムメールの話 - プログラマでありたい

    Gmailのカテゴリー機能がついて3ヶ月以上経ちました。改めて良い戦術だと思っています。メールサービスを提供する上で一番難しいのは、スパムへの対処でしょう。では、そもそもスパムの定義とは何でしょう?Wikipediaさんによると、次のように記述されています。 スパム (spam) とは受信者の意向を無視して、無差別かつ大量に一括して送信される、電子メールを主としたメッセージのことである。インターネット上での電子メール利用者の元に届く、事前に許可していない広告メールをスパムと呼んでおり、また、これはあまりに普遍的な現象や問題であるため、技術用語としても通ずる。電子メール以外の無差別かつ大量のメッセージの送信なども含まれることがある。日では電子メールを対象としたものについては、一般に「迷惑メール」と呼ばれる場合が多い。 ユーザからみたスパム 一般的な定義としては、上記の通りでしょう。しかし、

    周回遅れでGmailのカテゴリーとスパムメールの話 - プログラマでありたい
  • 家庭内ストレージ/NASのあれこれ。保存方法からバックアップ対象まで - プログラマでありたい

    はてブを見てると、NASやクラウドドライブなどストレージ関係のエントリーが幾つかあがっていました。私は、家庭内ストレージには比較的うるさいので一言いわせて頂きます。 家庭内でのストレージの種類 まずは一般的に家庭内のストレージはどういった種類があるのか整理してみましょう。主に下記の5種類くらいに分類出来るのではないでしょうか? パソコンのローカルストレージ(HDD/SSD) スマフォ/タブレットのデータ領域 NASなどのネットワーク接続型共用ストレージ Dropboxなどローカル同期型のクラウドストレージ Amazon S3やBitcasaなどのローカル非同期型のクラウドストレージ ストレージを考える上でのポイントは、速度・容量・価格の3点です。 まず速度については、パソコンからファイルを読み取るスピードです。小さいサイズのファイルだと余り問題になりませんが、動画系など大きなファイルだとこ

    家庭内ストレージ/NASのあれこれ。保存方法からバックアップ対象まで - プログラマでありたい
  • Public AMIを公開する場合のお作法 - プログラマでありたい

    一般的にPublic AMIとして公開する必要があるケースは少ないです。そのため、AMIを公開する際の情報は少なく、どうしたものかなぁとなります。私も試しにしてみたかったので、公開してみたことがあります。その際の注意点をまとめておきます。今回の手順は、Redhat系OSを想定しています。 ※実際、一度目は手順としてまとめておかなかったので、抜け・漏れが発生しました。 自分の痕跡を消す 公開鍵の消去 これ必須です。忘れるとAWSから注意が来ることもあるそうです。私は来たことありませんが。。。 echo "" > /root/.ssh/authorized_keys echo "" > /home/*/.ssh/authorized_keys ログの消去 接続元情報などが漏れるので、消去しておいてください。ここのログは稼働しているサービスによって可変ですので、任意のものを消してください。 ec

    Public AMIを公開する場合のお作法 - プログラマでありたい
  • 超高速開発と聞いて思うところ。或いは、アジャイル開発が目指すところ - プログラマでありたい

    先日はじめて、超高速開発という概念を聞きました。正直何のことかよく解らなくて、ネットで幾つか調べてみると、元々は日経コンピュータの特集から生まれた言葉で、その名を冠するコミュニティが立ち上がって話題になっていた模様です。コミュニティの発起人をみてみると、開発ツールベンダーが一同に会しているようです。なんだかなぁと思っている所で、主催者の中の一人の方が書いたブログを読んで趣旨が解りました。 (日の会で)改めて感じたのは、まだまだツールの認知度が低いということです。今は狭い市場を競合製品で奪い合うのではなく、ツールベンダーが一緒になって市場を拡大する時ではないでしょうか。 確かに開発の現場におけるツールの認知度・導入率を考えると、業界が一致団結して取り組むというのは納得です。しかし、それ以前にそもそも開発って何だというのを考える必要があるのではないでしょうか?解りやすいのでウォータフォールモ

    超高速開発と聞いて思うところ。或いは、アジャイル開発が目指すところ - プログラマでありたい
  • CAPの定理と分散データベースの話 - プログラマでありたい

    前回、セッションストアについて悩んでいますという何も解決しないエントリーを書いたら、はてブやTwitterで非常に沢山のコメントを頂きました。色々な考え方があって、非常に参考になりました。ありがたい限りです。別途、考えを整理してまとめようと思いますが、下記の2つの考え方が多いようです。 共用セッションストアの格納先を分散データベースにすれば良いよ セッション設計をちゃんとすれば、クッキーストアを使ってもセキュリティや容量の問題はないよ 私も、どちらかと言えば上2つの方針で考えています。一方で、分散データベースは一貫性を保証しつつ可用性を高めるのは難しいという基姿勢と、クッキーストアについては設計ミスや実装ミスが起こりうるという現実の中で、どう安全側に倒していけるかという点を考える必要があると考えています。今回は、分散データベースの一貫性について考えていることをまとめてみます。 CAPの定

    CAPの定理と分散データベースの話 - プログラマでありたい
  • アプリケーション・サーバのセッションの保存先の話 - プログラマでありたい

    Webシステムの方式設計をする際に、わりと悩むのがアプリケーション・サーバのセッション(session)の保存先です。アプリケーションサーバとは、TomcatやJBoss,IISやRuby on Railsなどで利用するUnicornやPassengerなどです。そもそもHTTPの基仕様がステートレスな為、状態を保持する為にはどこかに状態を保持する必要があります。その解決策がセッションになります。そこでセッションの保存戦略を考える必要があるのですが、アプリケーションサーバやサイトの用途や性格、扱うデータの気密性・重要性によっても変わってきます。 それ以前にセッションの保存先のことの呼び方の定番が何かすら解らなかったりします。セッション・ストアとかセッション・ストレージとか、はたまたセッション・マネージャーとか。今回は、セッション・ストアで統一します。 主なセッションストアの種類と保存戦略

    アプリケーション・サーバのセッションの保存先の話 - プログラマでありたい
  • 自律的なシステムを目指して!!第2回 JAWS−UG 神戸 開発運用の現場でのChef活用 - プログラマでありたい

    先日の【神戸】OpsWorks (Chef) 特集 !に参加&登壇してきました。正直なところ、Engine Yardの安藤さんやHiganWorks 澤登さん、クリエーションライン 浦底さんと日を代表するようなChefの人たちの間で、私が話をしても良いのか悩みました。Chefの説明や技術的な部分ではとても敵わないので、Chefなどを使って自動化して何を目指すのかという所を中心に話をさせて頂きました。 私にとって、自動化もアジャイルもDevOpsも手段でしかありません。目的とすることは、ビジネスで儲かりつつ働く人が楽できるモデルを作ることです。楽しつつ儲かるビジネスモデルであれば、手動でもウォーターフォール型でも何でもよいのです。でも、現状では我々の業界では競争は激化して、現状維持ではジリ貧という状況です。そうなると今まで通りのやり方では、単純に労働強化でしか対応出来ません。そうならない為

    自律的なシステムを目指して!!第2回 JAWS−UG 神戸 開発運用の現場でのChef活用 - プログラマでありたい
  • 何故、Chefなのか? - プログラマでありたい

    AWS界隈で今一番熱いテーマは何でしょうか?色々ありますが、自動化がその1つでしょう。そして、その実現手段としてChefを取り上げる人はかなり多くいると思います。何故、今この動きが出てくるのでしょうか? AWS登場前と登場後のサーバ構築 Chefのことを考える前に、AWS登場前と登場後のサーバ構築のプロセスを考えてみます。AWS登場前のオンプレミスサーバの構築の場合、最低でも見積もり⇒発注⇒製造⇒配送⇒設置⇒設定⇒デプロイという工程があると思います。 これに対して、AWSのアカウントが既にあれば、起動⇒設定⇒デプロイという3ステップでシステムが利用出来る状態になります。 AWSの意義 前述のことを考えるとAWSには、2つの意義があると言えます。まずクラウドという文脈で、コンピュータリソースを所有から利用へと変化させたことです。次に、コンピュータリソースを物理の制約から解き放ち、必要な時に必

    何故、Chefなのか? - プログラマでありたい
  • AWSで大量メール配信するなら、Amazon SESで決まり - プログラマでありたい

    何度かAmazon Simple Email Service(SES)の使い方の紹介をしてきましたが、そもそもSESとは何ぞやという話をしていなかったです。最近整理してたので、簡単にまとめてみます。 Amazon Simple Email Service(SES)とは? Amazon SESは、一言でまとめると、「信頼性の高いバルクメール送信サービス」です。まず、信頼性の高いの部分についてです。自身でSMTPサーバを運用したことがある人は解ると思いますが、近年SMTPサーバを運用するのは非常に面倒くさいのです。不正中継されないようにセキュリティホールを塞ぐのはもちろんのこと、SMTPサーバのレピュテーション(信頼性)を下げない為に不適切なメールを送っていないかの監視、バウンスメールの比率を下げる為に定期的に配信するメールアドレスのお掃除などが必要です。しかし、Bounceの返り方はメールサ

    AWSで大量メール配信するなら、Amazon SESで決まり - プログラマでありたい
  • JAWS-UG Osaka 第8回勉強会 Beginnersに参加&登壇してきました - プログラマでありたい

    先日のJAWS-UG Osaka 第8回勉強会 Beginnersに参加&講師として話してきました。 今回の勉強会の趣旨は、8回目を迎えるJAWS-UG大阪で初心に戻ってAWSのサービスを1つ1つ勉強していこうというものでした。それでいて、主要AWSのサービスを全て網羅しようという野心的なものでもありました。事実、24セッション、35サービスの説明がされていました。参加者も100名を超え、1ユーザグループの活動の中でここまで出来るのかと驚きを覚えました。 さて、私の担当ですが、課金についてと、SQS,SNS,SESについてで、それぞれ30分のコマでした。課金について30分話すって何だよと思わないでも無かったですが、初心者向けにElastic MapReduceを説明する玉川さんの絶望に比べれば大したことでは無かったようです。 当日の発表に向けて、せっせと下調べしつつ適時ブログにもアップして