* 参照した論文 + http://labs.google.com/papers/gfs-sosp2003.pdf * 特徴 + 安いPC(OSはGNU/Linux)で分散ファイルシステムを構築しています(*注1)。 + PCは壊れるという前提で設計しています(*注2)。このため、分散システムを構成するノードが壊れた時、データが失われないことと、自動で復旧できることに主眼を置いています。 + ファイルシステムを利用する側(アプリ)に、ある程度の想定を求めています。任意の利用ケースに対してそこそこのパフォーマンスを出す(=平均的に良い性能)のではなく、特定の利用ケースで性能を発揮できるように設計しています。 + 性能を発揮できる利用ケースは次のようなケースです。 ++ 主にサイズの大きいファイルを扱う(*注3)。 ++ ファイルへの書き込みは追記(append)が多い(ファイルの一部分を何度
実用 Go言語
業務プログラミングの現場でも採用されるようになってきたGo言語。文法はシンプルで学びやすいという特徴を持っていますが、複雑な要件を実現するには、プログラミング言語が提供する構成要素（文法やライブラリ）をさまざまに組み合わせる必要があります。 本書は、そんなGoを使う上でのポイントを単なる文法詳解ではなく「よりGoらしく書くには」「実用的なアプリケーションを書くには」といった観点から紹介します。 構造体やインタフェースの使い方からJSON、CSVファイル、Excel、固定長ファイルの扱い方、またログやテスト、環境構築など現場に即した幅広いトピックについて、「Goらしいプログラムの書き方」をその背景と共に教えてくれる先輩のような書籍です。 まえがき 1章 「Goらしさ」に触れる 1.1 変数やパッケージ、メソッドなどに名前を付けるには 1.1.1 変数名 1.1.2 パッケージ名 1.1.3
クックパッドに入って 3 年が経った
2012/4/2 にクックパッド株式会社に入社して 3 年が経過して、今日から 4 年目になった。 わたしはこの会社で中学卒業以降 3 年、つまり高校入学〜卒業くらいの時間を過ごしたことになる。この 3 年間実際ほとんど普通の高校生とかがするような勉強はほとんどできなかった。が、かわりに周囲の強いエンジニアにボコボコにされたおかげでなんとかエンジニアとして生きていけている。…いや、とりあえず数学とかに関してはちゃんとキャッチアップしないと死ぬとは思ってますよ。 そして去年、一昨年の日記あさったけど節目のまとめ書いてなかったんだなぁ、ということでここ数年の動きをまとめてみる。 1 年目 (2012) は前述のようにフルボッコにされていた年。うーん、主に負債返済業をしていた気がする。具体的に何やったとかはもうあまり覚えていないのだった。当時のコードを見ると結構笑える事がある。 2 年目 (20
はてなエンジニア Advent Calendar 2017の2日目です。 昨日は、id:syou6162 さんによるAWS Lambda上で鯖(Mackerel)の曖昧性問題を機械学習で解決しよう - yasuhisa's blogでした。 この記事は、人工知能学会 合同研究会2017 第3回ウェブサイエンス研究会の招待講演の内容を加筆修正したものです。 講演のテーマは、「自然現象としてのウェブ」ということでそれに合わせて、「自然のごとく複雑化したウェブシステムの運用自律化に向けて」というタイトルで講演しました。 一応、他の情報科学の分野の研究者や技術者に向けて書いているつもりですが、その意図がうまく反映されているかはわかりません。 概要 1. ウェブシステムの信頼性を守る仕事 2. ウェブシステム運用の現状 国内のウェブシステムの運用技術の変遷 クラウド時代 コンテナ型仮想化技術 サーバ
今年一年Kubernetes on AWSをやってきて、kube-awsメンテナ目線で、「今日から、できるだけ楽に、安定して本番運用」するための個人的ベスト・プラクティスをまとめておきます。 TL;DR EKSはまだプレビュー申込の段階。実際に動くものがあるかもわからない。 EKSとkops、kube-aws、kubesprayなどは組み合わせて使うもの。代替えにはならない。 SaaSありなら分散ログ、分散トレース、リソースモニタリングはDatadogに寄せると運用が楽 istioは安心して本番運用できるフェーズではない(Service Meshが必要なら、まだLinkerdのほうがよい) アプリケーションにPrometheusエンドポイントを生やしてメトリクスを取れるようにすべき アプリケーションはOpenTracingやZipkin、Jaegerなどのトレーサを組み込み、Zipkin
Chatworkテックリードが“今”の自分に集中してきた理由。Scala×DDDに出会い、サービス改善に生かすまで - Findy Engineer Lab
自分が気づいてなかった資質を、探して、磨く 劣等感に消耗するより、目的志向で考える オープンソースコミュニティへの参画 ドメイン駆動設計とScalaが「点」となる ドメイン駆動設計との出会いと成果 遅延評価的学習法でScalaを習得 Scalaを使ってDDDを実践するスタイルを確立した 実験的に導入して結果が出れば業務での普及も進む 積み上げてきたScalaとDDDの開発スタイル Scalaコミュニティとともに 新しい挑戦で新しい「点」ができ、そして「線」につながる 「いずれどこかで点がつながって実を結ぶだろう」 過去も未来も思い切って手放し、今の自分に集中する こんにちは、Chatworkでテックリードをしている、かとじゅん（@j5ik2o）です。 今年（2020年）で48歳になりましたが、技術に前向きになったというか、本気を出したのは37歳ごろでした。遅いな……（笑）。まぁ、遅い早いが
試験を受けるきっかけ 僕が入社した当初、資格取得を奨励していたこともあり、半ば強制でソリューションアーキテクト – アソシエイトの試験を受験させられました。今考えれば 完全にパワハラ ですよね。 それから2年後、iOS開発者として色々な案件に従事してきましたが、いろいろな領域の開発に興味が出てきたこともあって、サーバーレスアーキテクチャを採用した開発案件に飛び込みました。ちょうどその頃、 サーバーレス開発部 の立ち上げが重なり、 AWS の勉強を本格的に始めました。 SAP [期限: 2017-11-30] DOP [期限: 2017-11-30] Chatwork のタスクにこの２つが 部長 から追加されていたことは今でも忘れられません。 今考えれば 完全にパワハラ ですよね。ただ、労働基準局に駆け込むよりも「よし、やってやろう」という気持ちの方が大きかったです。取得した ソリューション
CAPの定理というのがある、 「ノード間のデータ複製において、同時に一貫性、可用性、分断耐性の3つの特性を同時に保証することはできない。」というもの。 説明をwikipediaにゆずると、 ・一貫性 (Consistency)： 全てのノードにおいて同時に同じデータが見えなければならない。 ・可用性 (Availability)： ノード障害により生存ノードの機能性は損なわれない。つまり、ダウンしていないノードが常に応答を返す。単一障害点が存在しないことが必要。 ・分断耐性 (Partition-tolerance)： システムは任意の通信障害などによるメッセージ損失に対し、継続して動作を行う。通信可能なサーバーが複数のグループに分断されるケース（ネットワーク分断）を指し、1つのハブに全てのサーバーがつながっている場合は、これは発生しない。ただし、そのような単一障害点のあるネットワーク設計
グーグルが「Evolution and Future Directions of Large-Scale Storage and Computation Systems at Google」（グーグルにおける、大規模ストレージとコンピュテーションの進化と将来の方向性）という講演を、6月に行われたACM（米国計算機学会）主催のクラウドコンピューティングのシンポジウム「ACM Symposium on Cloud Computing 2010」で行っています。 講演の内容を4つの記事（MapReduce編、BigTable編、教訓編、デザインパターン編）で紹介しています。この記事は教訓編の続き、デザインパターン編です。 大規模システムデザインの指針 よりよく使ってもらうためのインフラのデザインと開発方法を考えてみよう。 インフラに対する機能の要望についてさまざまなグループと話すと、多くのリクエ
C++の歴史
江添亮 http://cpplover.blogspot.jp/ boostcpp@gmail.com @EzoeRyou GFDL 1.3 with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. Themes Sky - Beige - Simple - Serif - Night - Default Transition Styles Cube - Page - Concave - Zoom - Linear - Fade - None - Default C++の原作者 Bjarne Stroustrup C++のオリジナルの設計者にして最初の実装者 1979年 Stroustrup、ケンブリッジで博士号を取得するべく研究中 分散システム上で動作するソフトウェアの研究 実証のため、大規模なシ
私が働いているAniqueという会社では、1年前に全てのソフトウェアでTypescriptを採用することにしました。私たちが開発している進撃の巨人のNFTサービス “Attack on Titan: Legacy” でも採用しています。 TypescriptではNestJSという素晴らしいAPIフレームワークを利用することができ、生産性高く開発を続けることができます。また、私たちはフロントエンドでNext.jsを利用しています。言語レベルでのコンテキストスイッチを抑えることで、一人のエンジニアがフロントエンドとバックエンドのどちらもの機能を開発する環境が作れました。 しかし、Nodeならではの作法や設計について、Web上にはたくさんの情報があるものの、あまりにも情報が多すぎて、まとまったプラクティスになかなか出会うことができませんでした。そのため、最初はチーム内での共通認識を作るのに苦労し
この記事は 食べログアドベントカレンダー2023 の23日目の記事です🎅🎄 こんにちは。食べログシステム本部 技術部 仕入チームの@shohei-yです。 今回は、新規事業の「食べログ仕入」プロダクト開発において所謂「設計書」を書かない設計に挑戦して開発効率を向上させた話を書きます。 （結局「書くの？書かないの？どっちなんだい！」と感じた人は、ぜひ読み進めてください。） 所属している仕入チームについてはこちらの記事をご覧ください。 目次 なぜ設計書を書かない設計に挑戦したのか 設計書を書かないチーム 設計書を書かないことによる問題 1. チーム協力の課題 2. ソースコードの複雑化 3. チーム変動に関わる問題 設計工程導入のきっかけ 設計書を書かない挑戦の背景 設計書を書かない設計 フロントエンド・バックエンドのインターフェースの明確化 ソースコードのスリム化対策 設計のレビュー方法
みんな大好きElastic Load Balancing(以下ELB)は利用にあたっては細かい仕様に注意する必要があります。 2014年ELBにお世話になった人もそうでない人も2015年はもっとELBを活用するために、改めてELBの仕様や活用方法を振り返ってみましょう。 ※本稿の内容の多くは一度でもELBを使ったことがある方を想定しています。 ELBが得意なところ ELBはコスト効果良く高い可用性と拡張性をもつロードバランサーをサービスとして提供してくれるので、最初に利用するロードバランサーとしても、長く使うロードバランサーとしても優秀です。 ELBを活用するためのドキュメントがAWSから公開されています。未読の方は必ず目を通しておきましょう。 Best Practices in Evaluating Elastic Load Balancing ELBが苦手なところ ELBを利用する上で
分散プログラミングモデルおよびデザインパターンの考察 その2 - Software Transactional Memo
前回の記事では 分散システムのデザインパターンと銘打っておきながら並列・並行システムの分野の話からクラウド環境へとこじつける事を「分散システム」と呼んだ事。 システム全体を決定づけるわけでもない通信パターン上の選択肢の一部を切り出してシステムの本質のように呼んだ事。 プログラミングモデルと言いながらプログラミングモデルの話が一切出なかった事。 のうち一番上についてしか書かなかったので次に真ん中の項目についての話をする。物事を分類する際の一般論としては MECE であることが好まれるがYahoo!の記事はレイヤーも目的も様々な物を一緒くたに語っており、取り繕おうにも議論の空間があやふやなので何に対して網羅的なのかも議論ができない。「マスターやワーカーというのは役割の議論であり通信パターンの議論ではない」「Producer-Consumerはデータフローの一種と呼べないのか？」「データフローは
Saturday, December 01, 2007 リーナス・トーバルズ「Subversion ほど無意味なプロジェクトはない」 Tech Talk: Linus Torvalds on git My hatred of CVS has meant that I see Subversion as being the most pointless project ever started. The slogan for Subversion for a while was "CVS done right" or something like that. And if you start with that kind of slogan, there is nowhere you can go. There is no way to do CVS right. ぼくの CVS への憎悪が
Mercari Microservices Platformの進捗（2019年） | メルカリエンジニアリング
Microservices Platform TeamでTech leadをしている@deeeeeeetです． 昨年のMTC2018ではMicroservices Platformチームの立ち上げから1年で僕らが取り組んできたことを紹介しました． speakerdeck.com 具体的にはStranglerパターンによるMonolithからMicroservicesへの段階的なリクエスト移行を行うためのAPI gatewayの開発や，Microservicesのインフラのセットアップを簡単にしサービス開発チームのSelf-service化を進めるためのStarter-kitの開発，GoでのMicroservicesの開発を高速で始めるためのTemplateプロジェクトの開発，Spinnakerの導入などについて紹介しました． これらはPlatformとして最低限の機能を整備したにすぎず，さ
2009年12月22日 2009年12月18日 2009年12月17日 2009年12月16日 2009年12月15日 2009年12月14日 2009年12月11日 2009年12月10日 2009年12月10日 2009年12月04日 2009年12月01日 2009年11月30日 2009年11月27日 2009年11月26日 2009年11月26日 2009年11月26日 2009年11月25日 2009年11月25日 2009年11月19日 2009年11月18日 2009年11月18日 2009年11月17日 2009年11月17日 2009年11月13日 2009年11月13日 2009年11月12日 2009年11月11日 2009年11月10日 2009年11月10日 2009年11月10日 2009年のプレスリリース一覧 ここに掲載されている情報は、発表日時点の内容です
(注：2017/04/20、いただいたフィードバックを元に翻訳を修正いたしました。修正内容については、 こちら を参照ください。) 要約 HTTP/2 にはHTTP/1.xに比べて多数の改良点がありますが、 カオステスト を行ったところ、HTTP/2のパフォーマンスがHTTP/1より劣る状況があることが分かりました。 ネットワーク上にパケット損失がある場合、TCP層での輻輳制御によって、少数のTCPコネクションの中に多重化されているHTTP/2ストリームがスロットリングされます。さらに、TCPリトライのロジックにより、リトライが行われている間、1つのTCPコネクションに影響しているパケット損失が、いくつかのHTTP/2ストリームに同時に強い影響を与えます。言い換えれば、ヘッドオブラインブロッキングが事実上、ネットワーク階層の レイヤ7 から レイヤ4 へ移動したということです。 背景とサー
Cloud Native時代における Docker / Kubernetes による開発 �Developers Summit 2019 at 02/14 / devsumi2019_amsy810_k8s
今日Dockerなどのコンテナ技術は広く普及し、GCP・Azure・AWSがマネージドサービスをリリースしたことなどからも、コンテナオーケストレーションエンジンとしてはKubernetesがデファクトスタンダードだと言えます。 本講演ではKubernetesが必要な理由・機能及びコンセプト・解決できる問題について、また分散システムとしてのKubernetesの仕組みについて紹介します。あわせて、コンテナを利用した開発をするにあたり切り離すことのできない「Cloud Native」や「マイクロサービス」の考え方、最近のKubernetesを取り巻く技術動向、将来性についても紹介します。 青山 真也 株式会社サイバーエージェント アドテク本部 Infrastructure Engineer Cloud Native Days Tokyo Co-chair／Japan Container Day
初のフライト変更ということで、羽田空港で5時間の待ち時間ができたのでブログを書いているところです。 皆さんの使用方法などを知りたいと思い、日本語で書かれたツイートやブログを時々みていますが、 共通で見受けられるElasticsearchに関する誤解があるようです。 よりよくElasticsearchを利用していただくために、よく陥る誤解とどうすれば良いかというのを紹介しようと思います。 誤解：2台でHA構成 「1台では、マシントラブルなどがあった場合に、Elasticsearchが利用できなくなるという心配から、2台でElasticsearchのクラスターを構成すれば1台ダウンしてもサービスを維持できるだろう。」 残念ながら2台では完全なHA構成にはならないのがElasticsearchです。2台構成のクラスターは、データの欠損という障害に対しては有効です。 が、1台故障してもクラスターが
データセンター内で使う BGP の基礎知識 - Cybozu Inside Out | サイボウズエンジニアのブログ
Neco プロジェクトの ymmt です。本記事では Neco のネットワークの実装を理解するために必要となる範囲で Border Gateway Protocol (BGP)の基礎知識を解説します。 BGP はインターネット全域の経路制御に使われているプロトコルで、非常に複雑なルーティング要件を実装可能ですが、本記事では詳説しません。対象読者は 「BGP？ 知ってる知ってる、インターネットのあれでしょ！」 という程度のソフトウェアエンジニアです。 以下、社内向けの解説文書からコピペしているので文体が変わります。悪しからずご了承ください。 ルーティングプロトコル BGP の概念 BGP の特徴 iBGP の動作 データセンター内での BGP 利用 まとめ ルーティングプロトコル ルーティングプロトコルとは、簡単に言えば目的の IPv4/IPv6 アドレスへパケットを送り届けるのにどのような
Google を支える技術 を読みました。 Google のバックエンドで動いている各種分散処理システムに関しては Google 自身から論文がいくつも発表されています。それらの論文をはじめとする比較的最近の情報ソースをベースに、ある程度かみ砕いて要所要所を紹介するという内容でした。加えて著者の西田圭介さんは OpenCobol (COBOL を C 言語に変換しコンパイルする gcc のフロントエンド) を開発された、技術的なバックグラウンドがしっかりしている方であるようで、内容は信頼できると思います。 自分はこれまで Google のバックエンドの各種ソフトウェアについては方々で耳にしていましたが、漠然と何をするものか程度のことしか知りませんでした。 Web 検索の基本的な仕組みと それにまつわる Google が直面した問題、特に大規模処理 それを支えるために開発された各種ソフトウェ
こんにちは。インフラストラクチャ本部の池原です。 このエントリはGREE Advent Calendar 2013 13日目の記事です。 グリーではミドルウェアの開発にHaskellを用いています。本日は、C/C++やJavaの経験はあるがHaskellは初めてだった私が、Haskellをミドルウェア開発に導入した際に戸惑った事をいくつかご紹介します。 私がHaskellを使い始めたのは１年半ほど前です。最初はOCamlに興味を持っていたのですが、すでに社内で利用者がいたこともあり、諸般の事情からHaskellを選択することにしました。 Haskellに対する私の第一印象はこのような感じでしょうか。 型システムが強力なので、つまらないバグでサービスを止める事態を避けられる。 他の関数型言語と比べて読みやすい（カッコをあまりつかわなくてもよい）。 Posix関連のライブラリが充実しており、シ
訳者まえがき 原著者 Maxime Beauchemin の許可を得て以下の記事を翻訳・公開しました。 medium.freecodecamp.org 原著者は、Apache Airflow や Apache Superset のクリエーターで、現在は Lyft で Data Engineer をしています。 データエンジニアの始まり（翻訳） 私は 2011 年にBIエンジニアとしてFacebookに入社しました。2013年に退職するときには、私はデータエンジニアでした。 昇進もしくは新しい役割に就いたわけではありません。そうではなく、Facebookは、私たちが行っていた仕事が伝統的なBIを超えていたことに気づいたのです。私たち自身のために作り出した役割は、まったく新しい専門分野でした。 私のチームはこの変革の最前線にいました。私たちは新しいスキル、新しいやりかた、新しいツール開発し、そ
プログラマならいつかは読んでおきたい(と言っておけばかっこいい)本10冊 - 2010-11-26 - きしだのはてな
昨日の技術力をあげたいプログラマが読んでおかないと話にならない本10冊は本自体にはあまり意味がなくでその技術分野が大事で、あとエントリーレベルのものが多かったので、今日は読み甲斐のある本を。 本棚に飾っておくとかっこいい本です。あと、本屋でまとめて買って持って帰れるなら、値段的にも重さ的にも、尊敬します。 ぼくが持ってない本や持っててもほとんど読んでない本がかなり含まれてます。「この人こんな本も読んでるんだー」などと無用に尊敬したらダメですよ。むしろ、そのように誤解させて尊敬させるための本です。 アルゴリズムデザイン 作者:Jon Kleinberg,Eva Tardos共立出版Amazon読んで面白いし、アルゴリズムカタログじゃなくて設計方法の解説が多いので、とてもいい本です。途中までは読んでるので続きを読まねば。 あとアルゴリズムの本としてはアルゴリズムイントロダクションが定番ですが、
クラウドのリージョンを丸ごと落とす過酷な試験を実現する「Chaos Kong」、Netflixが発表。「カオスエンジニアリング」の指針も表明
クラウドのリージョンを丸ごと落とす過酷な試験を実現する「Chaos Kong」、Netflixが発表。「カオスエンジニアリング」の指針も表明 動画配信サービスのNetflixが、Amazonクラウド上のサーバをランダムに落とすことでシステムの堅牢性をチェックするという画期的な考え方のツール「Chaos Monkey」を発表したのは2012年でした。 サービス障害を起こさないために、障害を起こし続ける。逆転の発想のツールChaos Monkeyを、Netflixがオープンソースで公開 Netflixは普段からChaos Monekeyでシステムをテストし続けていたおかげで、昨年10月にAmazon EC2の全インスタンスの約10％がリブートされるという大規模メンテナンスも難なく乗り切ることができたと報告しています。 そしてこのChaos Monkeyの成功に基づき、さらに過酷な状況をシミュレ
公用語に英語、「再起動」したRubyKaigi 2013が東京で開催：3万5000円の参加費でも内外から580人の参加登録 2013年5月30日から3日間、東京・台場の東京国際交流館で「RubyKaigi 2013」が開催された。RubyKaigiは2006年に第1回が開催されたRubyコミュニティが主催する年次イベントだ。ここ数年の実績では700～1000人の参加者を集める比較的規模の大きなイベントとなっている。ただ、2011年を「最終回」として、いったん終了した経緯がある。ボランティアベースでイベントを回すには規模が大きくなりすぎたことなどが背景にあったという。 1年のブランクを置いて、正式名称を「日本Ruby会議」から「RubyKaigi」と改めた上で今年再開した形だ。イベント企画チームは今回のイベント再開を「RubyKaigi第2シーズン」と位置付ける。それまで6000円前後だった
MessagePackフォーマット仕様のPull Request #209をマージし、MessagePackにTimestamp型を追加しました。 ※この記事の英語版は XXX にあります（翻訳中） Extension型の型コード -1 として定義されているため、後方互換性が維持されています。つまり、既にExtension型に対応しているデシリアライザであれば、Timestamp型を使用して作成されたデータを、Timestamp型に対応していない古いデシリアライズで読み出すことができます。 新しいTimestamp型には timestamp 32、timestamp 64、timestamp 96 の3つのフォーマットがあり、よく使う値をより少ないバイト数で保存できるようになっています。例えば、1970年〜2106年までの時刻で、秒までの精度しか持たない時刻であれば、合計6バイトで保存でき
訳：松尾真一郎 以前のポストで書いたように、ブロックチェーンはインターネット並の破壊力を持ち、多くの機会とイノベーションを解き放つポテンシャルを持つと思うし、各種トランザクションのための、普遍的で、互換性を持ち、信頼できる低コストなネットワークになる可能性があると思う。しかしブロックチェーンは巨大なポテンシャルを持つ一方で、インターネットとOpen Webで過去も現在も経験したものと、似てはいるが多くの点でとてもちがう課題にこの技術は直面している。 私は、ビットコインとブロックチェーンの現状を心配している。 一部にはこの業界への過大投資、また一部にはビットコインがインターネットなどよりはるかにお金がらみであるため、この技術はインターネット初期ではまったく類似例がなかった危機を経験している。それでもインターネットの形成過程は、いくつか重要な教訓を与えてくれる――特に重要な点として人材の問題と
SRE サイトリライアビリティエンジニアリング
サイトリライアビリティエンジニアリング（SRE）とは、Googleで培われたシステム管理とサービス運用の方法論です。GoogleのSREチームの主要メンバーによって書かれた本書は、ソフトウェアのライフサイクル全体にコミットすることで世界最大規模のソフトウェアシステムがどのように構築、導入、監視、維持されているのかを解説します。 はじめにリスク管理やサービスレベル目標、リリースエンジニアリングなどSREの行動の基礎となる原則について解説し、次にインシデント管理や障害の根本原因分析、SRE内でのソフトウェア開発など大規模分散コンピューティングシステムを構築し運用するSREの実践について詳述します。さらにSREのトレーニングやコミュニケーションなどの管理について紹介します。 急速にスケールするサービスを高い信頼性で運用する方法を解説する本書はエンジニア必携の一冊です。 本書への推薦の言葉 監訳者
CDNのエッジでJavaScriptとServiceWorkerを実行できる「Cloudflare Workers」がWebAssemblyに対応
CDNのエッジでJavaScriptとServiceWorkerを実行できる「Cloudflare Workers」がWebAssemblyに対応 CDNプロバイダのCloudflareは、3月にリリースした「Cloudflare Workers」を強化し、WebAssemblyの実行に対応したことを発表しました。 Cloudflare Workersは、同社が提供するグローバルなコンテンツデリバリーネットワーク（CDN）のエッジにおいて、開発者がJavaScriptのコードを配置し実行できる機能を提供します。また、HTML5の新機能として策定されたService Workerも利用可能です。 参考：JavaScriptのコードとService Workerをユーザーに近いCDNのエッジで実行可能。Cloudflareが「Cloudflare Workers」を提供開始 Service W
分散プログラミングモデルおよびデザインパターンの考察 その3 - Software Transactional Memo
昨日に引き続いて分散システムのデザインパターンについて書いていきたい。 だがそれ以前に故障モデルに関する前提を忘れてはならない。人によって様々な方針があるが、個人的には分散システムの世界において意識しなくてはならない故障モデルは4つだと考えている。僕は前回のブログに書いた Replication の本をベースに書いており、少し言葉遣いや定義が他とやや違う点は許して欲しい。また、通信の脱落・遅延とはレイヤーが異なる議論である。 故障モデルの分類 故障が起きないモデル これは故障が起きない世界を仮定するモデルである。これ自体はプロダクションにそのまま投入できるものではない。だがこの故障モデルを想定しても解けない問題は故障が発生する状況では絶対解けない事が断言できたり、合意プロトコルが正しいかを議論する土台となったり、様々な実用的なアルゴリズムや分散システムの土台となるアルゴリズムが生まれる土壌
時雨堂クラウドサービスを支える技術 v1
v2 へ移行中です 円安の影響や、自社製品がスケールアウトに対応したこと、Cloudflare LB の WebSocket の挙動が残念だったことなどを踏まえ、サービス構成を変更を検討中です。 自社サービスのバックエンドを Go から TypeScript へ切り替えるための整理 脱 Vultr Egress 料金が Linode だと Vultr の半額 Linode へ移行 脱 Cloudflare LB Linode の NodeBalancers へ移行 マルチリージョンでの利用は Linode の Akamai Global Load Balancer 公開待ち 脱 Cloudflare サポートに不安があるため Akamai へ移行 脱 TimescaledB 移行は Linode PostgreSQL の提供開始待ち OLAP は DuckDB + S3 互換オブジェクトス
bitlyでの分散システム構築から学んだこと
5月に開催されたBacon Conferenceで，bitlyのアプリケーション開発リーダのSean O’Connor氏は，毎月600億クリックを処理する分散システムの開発を通じてbitlyの開発者たちが学んだ，最も価値ある教訓について説明した。 分散システムとは何か？ 分散システムを定義する３大特性は，氏によれば，Wikipediaで簡単に見付けることができる。 コンポーネントノードの真の並行性。これによってノード間の同調に関連するコストと複雑性が発生する。 共通クロックの不在。このため，異なるノードで発生したイベントを時間順に並べることは不可能になる。 障害の独立性。これはノード障害がシステム内の他のノードに影響を与えない，という能力として理解されるべきだ。 従って分散システムの構築では，これらの特性を扱うことを目標にする必要がある。 ただし氏の意見として，システムの分散的特性に起因す
CRDT (Conflict-free Replicated Data Type)を15分で説明してみる - Qiita
CRDTについて勉強したので纏めてみました。15分くらいでざっとわかったつもりになれる感じで纏めてみたつもりです。 全体スライド Slideshareのスライドが埋め込めなかったので、↓からアクセスしてくださいm(-_-)m 下記はスライドの講演の書き下しのようになっているので、スライドだけ見るんじゃなくて、スライドを見ながら文章を読み進めたい方向けです。 CRDTとは 今回は、CRDTというデータ構造について紹介します。CRDTはそもそも2011年にSSS(Stabilization, Safety, and Security of Distributed Systems)という国際会議で、INRIA(フランス国立情報学自動制御研究所)のMarc Shapiro博士によって発表された、比較的新しいモノです。 CRDTは"Conflict-free Replicated Data Type
はじめに タイトルは釣りです（テンプレ） はじめましての方ははじめまして。特にこの記事がバズるとも思ってないんですが、なんとなく新しく僕のことを知っていただいた方のために自己紹介しておきます。 ZOZOテクノロジーズ開発部に所属するインフラエンジニアのようなことをやっている者です。チーム的にはMLOpsチームという組織にいます。Dockerが好きです。 社内では本名の太田さん、pchan、いんだくたーさん、こうちゃんなどと呼ばれています (Ref: @sonots) 自分のことを知っている方はご存知だと思いますが、自分語り満載のエントリーになる予定です。だるいと思った方はスルーしてもらって大丈夫です！ 入社の経緯とか そもそもの入社のきっかけは、前職で働いていた頃に遡ります。前職では小さな(?)Web制作会社で受託案件のPHPを書いたりAndroidアプリ(Java)の保守などをメインに担
趣味は何かときかれたらインターネット企業ウォッチですと答えるかもしれない。そのへんの企業ゴシップに気を取られるよりコードでも書いてた方が百倍くらい有意義だとわかってはいる。でもついニュースを眺めて過ごしてしまう。職業上の便益を損ねるくらいだからこれは趣味と呼んで差し支えなかろう。中でも各種企業イベントのキーノート・スピーチ鑑賞はそんなおっかけ業のハイライトだ。 インサイダーからすると、キーノートは学芸会みたいなもの。隣のクラスの出来映えにやきもきすると同時に、自分のコードの晴れ舞台、たった一つの台詞を見守る。 インサイダーでないキーノート・・・つまり大半のキーノートは、言って見れば近所の高校の文化祭に行くようなものだろうか。あ、こういう学校なんだ、これが流行ってるんだ、なんてのが透けて見える気がして面白い。メディアが報じるキーノートは空気を伝えない。自分でビデオをみてこそ愛好家というものだ
TL;DR 正しく設計するとキャパシティは常にカツカツになる これはpyspaアドベントカレンダーの8日目の記事です。前日はShibukawaさんです。 世はクラウド時代、ソフトウェアはひとたび作られたら何億回実行されても摩耗するものではないので、どんな間抜けなロジックであろうと動く以上は別のどこかで瑕疵が出てくるまで使い倒されるのは日常茶飯事である。 サービスを負荷の前提の上に定義する クラウドより前の時代においてサービスを支えるマシンは「ロードアベレージが1.0を超えてなければとりあえずOK、超えたらマシンを増やして負荷を分散する」というノリのベストプラクティスがよく言われていたがそれはサーバ資源の確保にそれなりに時間がかかる時代の常識であって、クラウド時代でサーバは分単位で確保できるようになった。 クラウドの利点としてその即時的なスケーラビリティが常套句として使われて久しいが、これは
強化学習の概要，応用上の利点，適用例，基礎理論，代表的手法，応用に必要な技術などの説明。 本ページの記述は下記の解説記事をもとにWEB用に修正したものである： 木村 元，宮崎 和光，小林 重信： 強化学習システムの設計指針， 計測と制御, Vol.38, No.10, pp.618--623 (1999), 計測自動制御学会. 6 pages, postscript file, sice99.ps (1.31MB) PDF file, sice99.pdf (148KB) 第１章： 強化学習の概要 1.1 強化学習 (Reinforcement Learning) とは? 1.2 制御の視点から見た強化学習の特徴 1.3 応用上期待できること 第２章： 強化学習の適用例：ロボットの歩行動作獲得 第３章： 強化学習の基礎理論 3.1 マルコフ決定過程(Markov decision proc
Envoy Proxyに入門した | Folioscope
最近 Kubernetes 周りの技術をよく触るのですが、Envoy Proxy (Envoy)もよく耳にするので勉強しました。 Envoy Proxy Envoy とは？ Envoy はクラウドネイティブな Web サービスのために設計されたロードバランサーです。 元は Lyft が開発しており、現在は CNCF (Cloud Network Computing Foundation) によって管理されています。 Envoy には大きく２つの用途があります。 サービスメッシュの通信バス: サービスメッシュ内の各サービス間の通信を制御するプロキシ。サービスディスカバリーや流量の制御をする。 エッジプロキシ: サービス内のプライベートネットワークとサービス外をつなぐプロキシ。データセンターや Kubernetes クラスタの外からのアクセスを受け付ける。 背景 モノリスで巨大な Web シス
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Google File System(GFS)技術メモ — ありえるえりあ
ウェブシステムの運用自律化に向けた構想 - 第3回ウェブサイエンス研究会 - ゆううきブログ
今日から始める人のためのKubernetes on AWSベストプラクティス - Qiita
iOSエンジニアとして入社した僕が AWS認定資格 11冠 になった話 | DevelopersIO
ITエンジニアのCAPの定理 - from scratch
グーグルが構築した大規模システムの現実、そしてデザインパターン（4）～デザインパターン編
“Tao of Node - Design, Architecture & Best Practices” 日本語翻訳
設計書を書かない設計で開発効率を向上させた話 - Tabelog Tech Blog
もっとELB（Elastic Load Balancing）を活用する | DevelopersIO
satolog: リーナス・トーバルズ「Subversion ほど無意味なプロジェクトはない」
IBM スマートな社会を支えるITインフラストラクチャーを提唱 - Japan
カオステストでHTTP/2の問題を見つけ出す | POSTD
Elasticsearchの運用に関する典型的な4つの誤解 | Elastic
Google を支える技術 - naoyaのはてなダイアリー
Haskell使ってみた | GREE Engineering
(翻訳) データエンジニアの始まり - satoshihirose.log
公用語に英語、「再起動」したRubyKaigi 2013が東京で開催
Blog by Sadayuki Furuhashi
ビットコインとブロックチェーンに関する現状に関する私の視点 - Joi Ito's Web - 日本語
ZOZOテクに入社してもうすぐ1年半になるので、リアルな話をしたい - inductor's blog
趣味はキーノート鑑賞 - steps to phantasien
正しいクラウドはある意味で遅い - Software Transactional Memo
強化学習とは？(What is Reinforcement Learning?)