タグ

architectureに関するs_naganoのブックマーク (6)

  • ムーアの法則、終焉 | ライフハッカー・ジャパン

    ギズモード・ジャパンより転載:インテルを抜き去るライバルも? 年を追うごとに半導体製造プロセスが向上し、コンピューター業界の目ざましい進化が演出されてきた時代が、終焉とまではいかないものの、大きくスローダウンを迎えそうです。この進化スピードを表現した「ムーアの法則」は、インテルのゴードン・ムーア氏が提唱したもの。半導体チップ上のトランジスタ数は18カ月ごとに倍増していくとの理論が発表され、まさにその速度で進化が続いてきました。後にムーアの法則も、半導体チップ上のトランジスタ数は24か月ごとに倍増するというサイクルまでペースダウン。ところが、ついに2年ごとの製造プロセスの向上という目標にも届かなくなったことが、新たにインテルによって発表された「Form 10-K」有価証券報告書で確定してしまった形ですね。 これまでインテルは、ムーアの法則を実現するTick-Tockモデルの開発サイクルを守っ

    ムーアの法則、終焉 | ライフハッカー・ジャパン
    s_nagano
    s_nagano 2016/03/30
    サイクルが遅れてきたってこと
  • ロードバランサのアーキテクチャいろいろ - yunazuno.log

    少し前に,Facebookのロードバランサが話題になっていた. blog.stanaka.org このエントリを読んで,各種Webサービス事業者がどういったロードバランスアーキテクチャを採用しているのか気になったので調べてみた. ざっくり検索した限りだと,Microsoft, CloudFlareの事例が見つかったので,Facebookの例も併せてまとめてみた. アーキテクチャ部分に注目してまとめたので,マネジメント方法や実装方法,ロードバランス以外の機能や最適化手法といった部分の詳細には触れないことにする. 事例1: Microsoft Azure 'Ananta' MicrosoftのAzureで採用されている(いた?)ロードバランサのアーキテクチャは,下記の論文が詳しい. Parveen Patel et al., Ananta: cloud scale load balancing

    ロードバランサのアーキテクチャいろいろ - yunazuno.log
  • Software Defined ArchitectureとミサワホームAWS活用事例に見る「デジタルビジネス時代のIT活用」

    Software Defined ArchitectureとミサワホームAWS活用事例に見る「デジタルビジネス時代のIT活用」:ITのパフォーマンスはビジネスのパフォーマンス 先を見通しにくい中で、安定的に収益・ブランドを向上させ続けるためにIT部門ができることは何か? デジタルビジネス時代のアプリケーション開発、インフラ活用の要件を探る。 “ITのパフォーマンスがビジネスのパフォーマンスを決定する”デジタルビジネス時代、アプリケーションアーキテクチャやアプリケーションを支えるインフラにも“新しい在り方”が求められている。とりわけモバイル、ソーシャルが社会一般に広く浸透している今、SoE(System of Engagement)と呼ばれる顧客接点となるシステムを中心に、スピーディな開発、改善、拡大あるいは廃棄といった市場環境変化に応じた柔軟・スピーディな展開が一層重要となっている。 では

    Software Defined ArchitectureとミサワホームAWS活用事例に見る「デジタルビジネス時代のIT活用」
    s_nagano
    s_nagano 2015/04/26
    ITのパフォーマンスはビジネスのパフォーマンス:Software Defined ArchitectureとミサワホームAWS活用事例に見る「デジタルビジネス時代のIT活用」 - @IT
  • 世界最強のソフトウェアアーキテクト

    ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは! マーケティングソリューションカンパニー(MSC)開発部の小川雄大です。 昨年11月に子会社のクロコスからヤフーに移りまして、現在はヤフーで開発を行っています。みなさまどうぞよろしくお願いします。 MSC開発部では、ヤフーが世界最強を目指してどう取り組んでいくかについて議論する会を毎週開催しています。今回はそこで今年の1月に僕が発表した「世界最強のソフトウェアアーキテクト」について公開したいと思います。 今回はヤフーに入ってはじめての発表ということもありテーマをどうしていくかはかなり悩んだ部分なのですが、テクニックよりもアーキテクトが持つべきマインドを共有することが次につなげていく上で大切になると考えたので、多少抽

    世界最強のソフトウェアアーキテクト
  • Martin Fowler's Bliki in Japanese - 犠牲的アーキテクチャ

    @@ -0,0 +1,37 @@ +http://martinfowler.com/bliki/SacrificialArchitecture.html + + +会議の席であなたは考えている。自分のチームが二年間かけて書いてきたコードのことを。そして決断に至る。いま打てる最善の手は、あのコードをすべて投げ捨てまったく新しいアーキテクチャを再構築することだ。死にゆくコード、それに費やした時間、自分が下し続けてきた判断。この決断は、あなたはどんな気持ちにするだろう? + +多くの人にとって、コードを捨てるのは失敗の証だ。ソフトウェア開発の探索的な性質を考えれば、わからない判断ではないかもしれない。けれど失敗には違いない。 + +ところが、いま書ける最良のコードは二年経ったら捨てるつもりのコードだということはよくある。 + +私たちは長命なソフトウェアとして偉大なコードを思

    Martin Fowler's Bliki in Japanese - 犠牲的アーキテクチャ
  • なぜTwitterは低遅延のままスケールできたのか 秒間120万つぶやきを処理、Twitterシステムの“今” − @IT

    ユーザー同士のつながりを元に時系列に140文字のメッセージを20個ほど表示する――。Twitterのサービスは、文字にしてしまうと実にシンプルだが、背後には非常に大きな技術的チャレンジが横たわっている。つぶやき数は月間10億件を突破、Twitterを流れるメッセージ数は秒間120万にも達し、ユーザー同士のつながりを表すソーシャル・グラフですらメモリに載る量を超えている。途方もないスケールのデータをつないでいるにも関わらず、0.1秒以下でWebページの表示を完了させなければならない。そのために各データストレージは1~5ms程度で応答しなければならない。 Twitterのリスト機能の実装でプロジェクトリーダーを務めたこともあるNick Kallen氏が来日し、2010年4月19日から2日間の予定で開催中の「QCon Tokyo 2010」で基調講演を行った。「Data Architecture

  • 1