各種アーキテクチャのクロスコンパイラ環境を構築する - ももいろテクノロジー
Docker上に作成したDebian 8環境にてbinutils、gcc、glibcをソースコードからビルドし、さまざまなアーキテクチャのクロスコンパイラ環境を構築してみる。 なお、構築した環境は次のDocker imageとして公開してある（イメージサイズが2.8GBと大きいことに注意）。 inaz2/debian-crossbuild 環境 Ubuntu 14.04.3 LTS 64bit版、Docker 1.9.1 $ uname -a Linux vm-ubuntu64 3.19.0-25-generic #26~14.04.1-Ubuntu SMP Fri Jul 24 21:16:20 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux $ lsb_release -a No LSB modules are available. Distributo
Wandboxを支える技術
Wandbox とは 普通の C++ 使いは日常的に仕様書を読んでいる その際、実際にコンパイラを動かして試したくなる場合がある 例: 「ISO/IEC 14882:2011 における 3.4.2/2 が結果がどうなるのかよく分からないな」 「現行の gcc/clang でどういう動作をするのか試してみたい」 普通の C++ 使いは日常的に paper を読んでいる その際、実際にコンパイラを動かして試したくなる場合がある 例: 「N3648 が gcc で実装されたのか」 「最新の gcc でどういう動作をするのか試したい」 普通の C++ 使いは日常的にコンパイラのバグを報告している その際、実際にコンパイラを動かして試したくなる場合がある 例: 「std::negative_binomial_distribution がコンパイルエラーになるバグって直ったんだっけ？」 「最新の gc
第12回 複数のプロセスにおける協調動作のための仕組み─コーディネーション | gihyo.jp
はじめに 前回は、分散システム技術を基本とする耐障害性のための仕組みとして、レプリケーションとロギングについて述べました。今回は、分散システムにおいて複数のプロセスが協調して動作するための仕組みであるコーディネーションについて、その概要を説明します。 コーディネーションとは 並列データ処理系におけるコーディネーションは、複数のプロセス間において、協調して動作をする、または、同意を取るための技術です。すなわち、コーディネーションを行うことにより、並列データ処理系における複数のプロセスが同じ目的（もしくは値）を共有し、各々がその目的のもとで何らかの処理を実行できるようになります。当該技術は、たとえば、複数のプロセスにおける状態やレプリカ間の値の一貫性を保つために用いられます。 コーディネーションにおいては、多くの場合、次のことを前提として議論されるため、特に明示的に言及しない限り、本連載におい
「基本設計を分担してはいけない」わけねーよという話 - novtan別館
こういう話をするときに前提というか設定というかそういうのが雑なままで進めるとさっぱり話のフォーカスが合わない。という話になっている時点で「そりゃ分担したら上手く行かないよな」と思ってしまうわけで、つまりこの話は定量的・定性的な分析ではなくて個人の体験談なんだろうな、と思った次第。 私がとくに不思議に思うのが、基本設計を何人もの要員で分担するやり方だ。DB設計と機能設計と業務設計の担当を分けるとか、サブシステム毎に担当を分けるといった体制がしばしば敷かれる。詳細設計の段階でというのならまだわかるが、基本設計でそれをやってはいけない。 基本設計を分担してはいけない: 設計者の発言 もういきなりわからないのが「何人もの」で、１人じゃないとダメなのか、何人までならいいのかとかそういうどうすべきかの話がわからず、DB設計がインフラの話なのかモデルの話なのかネーミングの話なのかもわからない。え、それ全
The Reactive Manifesto 日本語訳 - 自由課題
まえがき ガートナーのレポートやInfoQの記事なんかをみると、リアクティブプログラミングというのがこれからくるよ、というのが書いてあったので少し前にちょっと調べていました。その時にアジャイルマニフェストみたいな感じでThe Reactive Manifestoという文書があったのでその時はザクッとみてふーんという感じだったのですが、最近見返そうと思ったらまだ日本語訳がありませんでした。 なので、もうちょっと詳しく読むついでに原文を書いた(一人である)Jonas Bonérさんに日本語訳を書いていいか聞いてみたら(今みたらこの時点で英語が若干間違えてる...)、 @kimito_k Absolutely not. Excellent. Thanks. Let me know when you publish it.— Jonas Bonér (@jboner) 2014, 1月 15 とわ
Jenkinsコードリーディング - JDK自動インストールの謎を追え - Qiita
TL;DR 自動インストールでインストールされるJDKのアーキテクチャは、各Nodeを登録するために起動するslave.jarのJREのアーキテクチャだよ Jenkinsのソースコードは構造のバランスがいい Jenkinsは週次リリースできるソフトウェアのアーキテクチャを学ぶ題材として最適 きっかけ Jenkinsの便利な機能に、JDKの自動インストールがある。プロジェクトに利用するJDKを設定すれば、実行するノードに自動でJDKをインストールしてくれる、という素晴らしい機能だ。WindowsやLinuxだと32bit、64bitのJDKが配布されているので、どうやってインストールするJDKを判定してるんだろう、と思ってコードを読み始めた。 ゴール 自動インストールを実装しているクラスを見つけ、どのように実装されているか理解すること 実装クラスを見つける 実装を見つけるときは、ログを出力し
Automation Accountパターン - 世界線航跡蔵
コンテキスト あなたが開発しているサービスはユーザー向けにAPIを提供している。そして、APIを利用するにはユーザーは短寿命の認可情報(たとえばOAuth2トークン)を提示しなければならない。 ユーザーは認可情報が紐付いているアカウントの権限でリソースを読み取ったり、作成したり、所有したり、編集または削除したりする。 ここで、ユーザーは人間(が操作するユーザーエージェント)であることもあるが、人間の手を離れてバックグラウンドで自動実行されるプログラムかもしれない。 また、あなたは悪用目的でアカウントが大量登録されるのを防ぐためにCaptchaを利用したいと思っている。 さらに、課金目的で請求書送付先を登録させたいとも思っているかもしれない。 問題 プログラムが利用するアカウントを安全に管理するのがユーザーにとって困難である。 プログラムは自分でCaptchaを解いたりEメールを受け取るのが
2015年Webサーバアーキテクチャ序論 - ゆううきブログ
2023年03月31日追記：この記事を基に、@sadnessOjisanさんより、コードレベルにより踏み込んだ、かつ、グリーンスレッドベースの新しいWebサーバアーキテクチャも含めて整理された記事 Webサーバーアーキテクチャ進化論2023 | blog.ojisan.io が公開されました。 主に新卒のWebエンジニア向けに、古典的なWebサーバアーキテクチャを学ぶ道のりと代表的な実装モデルの概要を紹介します。 この辺りの話題がWeb界隈で流行っていたのは数年以上前というイメージですが、Webサービスは相変わらずWebサーバの上で動いているので、流行り廃り関係なく学ぶべき内容だと思っています。 また、HTTP/2がいよいよRFC化し、既にh2oやtrusterdなどのHTTP/2のサーバ実装があり、今後Webサーバアーキテクチャを再訪することが増えるような気がしています。 ところが、We
Mackerelを支える時系列データベース技術 - ゆううきブログ
【追記 2018/01/06】現在Mackerelは、時系列データベースという概念をクラウドの技で再構築する - ゆううきブログの時系列データベース実装へ移行しています。 サーバモニタリングサービス Mackerel で採用している時系列データベース Graphite を用いたシステムの構築と運用事情を紹介します。Graphiteについては、プロビジョニングやアプリケーションからの使い方、Graphite自体のモニタリングなど様々なトピックがありますが、特に大規模ならではのトピックとして、Graphiteの内部アーキテクチャ、パフォーマンスチューニングおよびクラスタ構成についての知見を書きます。 背景 Graphiteシステム概観 データ構造とアーキテクチャ whisperのデータ構造 carbon-cacheのアーキテクチャ パフォーマンス特性 パフォーマンスチューニング ミドルウェアレ
確率的に犠牲的 - steps to phantasien
Martin Fowler が Sacrificial Architecture と言い出した時は驚いた。“変化を受け入れよ” はどこにいったの。書き直しはダメと自分の中の結論が出たのは随分前のことだけれど、ひさしぶりに考え直してみる。 Sacrificial Architecture の論拠として Martin Fowler はいくつかのインターネッツ企業を例にとっている。でも一般化するには偏ってないか。それにこれら企業が面していたのはごく限られた種類の変化だ: 彼らはもっぱら性能不足と戦っていた。 機能の変化に強いコードは柔軟性の裏で性能を犠牲にしがち。機能の変化を捉えることに先鋭化した従来の Agility は性能要件の変化を必ずしもやり過ごせない。一方で存在感を増すスタートアップの世界では性能への期待が当たり前のように大きく変わる。だから Agile はあてにならない、堅牢なアーキ
Stack Overflowの裏側は、Webサーバ9台、SQL Serverが4台など。月間5億6000万PVをさばくシステムの状況を公開中
ITエンジニアのコミュニティサイトStackOverflowなどを運営するStackExchangeが、同社のサービスを支えているシステム構成の状況を知らせるWebサイトを公開しています。 同社のサービスは各国版のStack Overflowのほかにも、サーバ管理者のためのServer Fault、数学関係者のためのMathematicsなど多岐にわたっています。 これらを合わせた同社のサービスは月間5億6000万ページビュー。このページビューを、48GBのメモリを搭載した9台のWebサーバ。384GBのメモリを搭載しライブ／ホットスタンバイ構成にクラスタ化した2台のSQL Serverと、288GBのメモリを搭載した2台のSQL Serverによるもう1つのクラスタの合計4台のSQL Server。96GBのメモリを搭載し、マスター／スレーブ構成にした2台のRedis Serverなどで
立て直しのケーススタディ - ワザノバ | wazanova
http://jacquesmattheij.com/saving-a-project-and-a-company 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約4時間前 日次のアクセスが1万人以下なのにサイトパフォーマンスが悪いシステムの立て直しを頼まれたJacques Mattheijjが、5週間で行った対応を紹介してくれているケーススタディです。 システム構成 Rails + PostgreSQL + Redis + AnguarJS + Symfony2 CentOS / HPブレード8台 （128G RAMと複数のVMware）、大型HPストレージアレー、Windowsマシン、Javaアプリ専用マシン 全体所見 アプリは概ね問題なし。システムレベルで非効率が散見され、開発の期限が近づいた時点で、雑な
「アーキテクチャは組織構造に従う」という経験則には2つの意味がある - プログラマの思索
「アーキテクチャは組織構造に従う」という経験則には2つの意味があるのではないか、というアイデアについてラフなメモ書き。 【元ネタ】 akipiiさんはTwitterを使っています: "これに今悩んでる。RT @sys_architect1: アーキテクチャは、ステークスホルダーのニーズを満たすためだけに作成される。また、優れたアーキテクチャとは、ステークスホルダーの目的や目標及びニーズと見事に一致しているもののことである。p.21" akipiiさんはTwitterを使っています: "「アーキテクチャは組織構造に従う」という経験則には2つの意味があると思う。1つは、サイロ型組織の構造はそのままソフトウェアに反映されて複雑な仕組みになってしまうこと。例えば、4つのチームでコンパイラを作ると無駄な4パスコンパイラになる。1パスコンパイラでいいのに。" akipiiさんはTwitterを使ってい
Cephがスケールできる理由、単一障害点を排除する仕組み、負荷を減らす実装
Cephがスケールできる理由、単一障害点を排除する仕組み、負荷を減らす実装：Ceph/RADOS入門（4）（1/4 ページ） Ceph／RADOS が採用しているCRUSH、Paxosといった、分散したデータから正しく応答するための仕組みを支えるアルゴリズムの概要を学びながら、挙動を見ていきます。 連載バックナンバー 本連載では、オープンソースの分散オブジェクトストレージであるCeph/RADOSの技術詳細、実装について見ていきます。第1回ではCephの概要を、第2回ではCeph/RADOSを構成する要素を、第3回では実際にインストールして動作させるところまでを見てきました。 第4回である今回は、Ceph/RADOSの動作する仕組みについて、採用している分散アルゴリズムや単一障害点をなくす仕組み、メタデータ削減の方法などを見ていきます。 Ceph/RADOSのアーキテクチャ概要 Ceph/
トレタのシステムアーキテクチャと恵比寿のメシと酒 : TORETA（トレタ） ブログ
ちわす。11月にサーバサイドエンジニアとしてジョインした佐野です。前職ではウェブサービスやソーシャルゲームのサーバ管理、DBA、運用ツール開発など主にインフラ面を担当していました。入社一ヶ月のペーペーでございます。 「ブログ書けやー」とのお達しが出たのですが、ノリがイマイチわからんので、軽い記事(恵比寿のメシと酒)と真面目な記事(トレタのシステム)を両方書きます。真面目な話の合間にメシの話でもしながら...。真面目な記事はエンジニア職向けの内容になります。 ではよろしくお願いします。 トレタのシステムは種々のクラウドサービスで成り立っています。この一ヶ月で僕がシステムに手を加えた部分としては、監視周りの整備(Pingdom, PagerDuty導入, 監視用hubotを書く)、ログ解析基盤の構築(fluentd -> BigQuery連携)、ちょっとした負荷分散(リバースプロキシを少々)を
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
CQRSに対する批判的見解
Microserviceなんて最初からやるもんじゃ無かった
メッセージング基盤の進化 Erlang、SPDYからそれを支える組織の話 LINE Platform Development Chronicle #linedevday
アーキテクチャ、技術、そしてアンチパターン「溶岩流」
NewsPicks を支える技術と怖い話
