タグ

ブックマーク / yakst.com (29)

  • 責任ある開発者のためのHTTPヘッダー | Yakst

    安全で、誰にも手頃でアクセスしやすく、ユーザーを尊重したWebを作るためのHTTPヘッダーのプラクティス [UI/UX]原文 HTTP headers for the responsible developer - Twilio (English) 原文著者 Stefan Judis 原文公開日 2019-04-23 翻訳依頼者 翻訳者 meiq 翻訳レビュアー doublemarket msh5 原著者への翻訳報告 1821日前 メールで報告済み 編集 This article was originally published on twilio.com, and translated with the permission of Twilio and the author. 当記事の原文はtwilio.comにて公開されたものであり、Twilio社および原著者の許可を得て翻訳しています

    potato777
    potato777 2019/06/16
  • MySQLのコネクションハンドリングとスケーリング | Yakst

    MySQLのコネクションハンドリングの内部構造、スケール限界、そして最大コネクション数のチューニングなどについてご紹介します 免責事項 この記事はGeir Hoydalsvik氏によるMySQL Server Blogの投稿「MySQL Connection Handling and Scaling」(2019/3/19)をユーザが翻訳したものであり、Oracle公式の文書ではありません。 この投稿では、MySQLのコネクション、ユーザースレッドおよびスケーリングについて取り扱います。MySQLがどのように動作するかをよりよく理解することで、アプリケーション開発者やシステム管理者が、トレードオフを踏まえた良い選択をできることでしょう。記事ではコミュニティー版でコネクションがどのように動作するかについて述べますが、一方でスレッドプール、リソースグループ、あるいはコネクション多重化といった関

    potato777
    potato777 2019/05/20
  • 多分あなたにKubernetesは必要ない | Yakst

    trivago社の小規模な開発チームがコンテナオーケストレーターとしてKubernetesではなくNomadを採用することになった経緯と理由について、両プロダクトの特徴やユースケースに言及しつつ紹介されています。 [HashiCorp][Kubernetes]原文 Maybe You Don't Need Kubernetes (English) 原文著者 Matthias Endler 原文公開日 2019-03-21 翻訳依頼者 翻訳者 msh5 翻訳レビュアー doublemarket 原著者への翻訳報告 2009日前 Twitterで報告済み 2008日前 原著者承諾済み 編集 スクーターに乗った女性(イラスト画像の作成元はfreepik、NomadロゴはHashiCorp) Kubernetesはコンテナオーケストレーションの巨人です。世界中で巨大なデプロイメントを動かしています

    potato777
    potato777 2019/04/02
  • GitHubのRails離れと、迫りくるMicrosoft | Yakst

    Microsoftによる買収が発表されたGitHubは、これまでどう進化し、今度どうなっていくのか?開発者プラットフォームとしてのGitHubが目指す未来を、同社のSam Lambert氏がプログラミング言語、データセンター戦略、AIといった様々な観点から語る。 [Ruby on Rails]原文 GitHub goes off the Rails as Microsoft closes in (English) 原文著者 Thomas Claburn (The Register) 原文公開日 2018-08-16 翻訳依頼者 翻訳者 mkasasagi 翻訳レビュアー doublemarket taka-h 原著者への翻訳報告 1888日前 メールで報告済み 1878日前 原著者承諾済み 編集 プラットフォーム改造で変わる「Ruby専門店」。今後はGoJavaKubernetesへ。

    potato777
    potato777 2018/09/27
  • CPU使用率は間違っている | Yakst

    Netflixのパフォーマンスエンジニアである筆者からの、topコマンドなどで表示されるCPU使用率(%CPU)は、いまや当の使用率を表しておらず、チューニングなどのための指標として使えないという指摘。なぜそうなってしまったのか、何を見れば当のCPU使用率がわかるのかをわかりやすく解説した記事。 私たちみんながCPU使用率として使っている指標は非常に誤解を招くもので、この状況は毎年悪化しています。CPU使用率とは何でしょうか?プロセッサーがどのくらい忙しいか?違います。CPU使用率が表しているのはそれではありません。私が話しているのは、あちこちで、あらゆる人たちに、あらゆる監視製品で、あるいはtop(1)でも使われている、"%CPU"という指標のことです。 あなたの考えているであろうCPU使用率90% : 実際 : "stalled"(訳注 : 以下ストールと言う)とは、プロセッサーが

    CPU使用率は間違っている | Yakst
    potato777
    potato777 2017/06/16
  • GitLabのデータ消失に対するアドバイス | Yakst

    GitLabのデータベースが消失してしまった事故に関して、PostgreSQLのコミッターであり、PostgreSQLに関するコンサルティング会社2ndQuadrantのCTOでもあるSimon Riggs氏からの分析とアドバイス。 GitLabのみなさん、PostgreSQL 9.6とレプリケーション機能、バックアップの仕組みを使ってくれてありがとう。 今回、GitLabのデータベースが消えてしまったのは残念です。 https://about.gitlab.com/2017/02/01/gitlab-dot-com-database-incident/ 振り返りの分析に対するコメントができるように、こういった情報を公開してくれてどうもありがとう。 レプリケーションの遅延を監視していたのはいいことですし、私としてはとてもうれしいです。4GBのレプリケーション遅延は問題ないこともありますし、

    potato777
    potato777 2017/02/07
  • git diffコマンドで比較する時のダブルドット(..)とトリプルドット(...)の違いとは? | Yakst

    Gitでブランチ(コミット)間の違いを表示するgit diffコマンドに存在するダブルドット(..)記法とトリプルドット(...)記法の違いについて、Stackoverflowの分かりやすい回答。 「git diffコマンドで比較する時のダブルドット(..)とトリプルドット(...)の違いとは?」という質問へのMark Longair氏の回答 git diffコマンドは通常(「通常」というのは、例えばマージコンフリクトを解消する際などには3ウェイマージを表示することがあるため)、コミットグラフにおける完全な2つのポイント間のツリーの状態の違いを表示します。git diffでの..と...の表記は、以下の意味になります。 言い換えると、git diff foo..barはgit diff foo barと完全に同じです。どちらも2つのブランチfooとbarの最新の変更同士の違いを表示します。

    git diffコマンドで比較する時のダブルドット(..)とトリプルドット(...)の違いとは? | Yakst
  • 6万ミリ秒でできるLinuxパフォーマンス分析 | Yakst

    NetflixのシニアパフォーマンスアーキテクトであるBrendan Gregg氏による、Linuxサーバにログインして60秒でまず調べることのまとめ。 パフォーマンス問題でLinuxサーバーにログインしたとして、最初の1分で何を調べますか? Netflixには、多数のEC2 Linuxからなるクラウドがあり、そのパフォーマンスを監視したり調査したりするための数々のパフォーマンス分析ツールがあります。その中には、クラウド全体にわたる監視を行うAtlasや、オンデマンドにインスタンスの分析を行うVectorがあります。これらのツールは多くの問題を解決する手助けをしてくれますが、各インスタンスにログインし、標準的なLinuxパフォーマンスツールを実行する必要がある場合もあります。 この記事では、すぐ使えるはずの標準的Linuxツールを使いコマンドラインにおいて、最適化されたパフォーマンス調査を

    6万ミリ秒でできるLinuxパフォーマンス分析 | Yakst
  • InfluxDBの新しいストレージエンジン : 時間構造のマージツリー (InfluxDB Blogより) | Yakst

    時系列データのユースケースに合わせた新しいストレージエンジンについて紹介する。新エンジンは列指向フォーマットを採用、フィールドのデータ型およびタイムスタンプの精度に応じた圧縮技術を利用することで高圧縮率を実現する。LSMツリーと類似した構造を持ち、WALおよび読取り専用のインデックスファイルを持ち、古いデータが圧縮される。 出典について この記事はInfluxDB BlogのPaul Dix氏によるThe new InfluxDB storage engine: a Time Structured Merge Tree(2015/10/7)を翻訳したものです。 1年以上にわたって、我々の時系列データのユースケースに合わせたストレージエンジンを作るかもしれない、とお話ししてきました。日、新しいストレージエンジンの最初のバージョンが、ナイトリービルドからテスト用に利用できるようになったことを

    InfluxDBの新しいストレージエンジン : 時間構造のマージツリー (InfluxDB Blogより) | Yakst
  • こんなコーディングは退屈だ! | Yakst

    Enkiのco-founderで最高技術責任者(CTO)であるBruno Marnetteが、エンジニア仕事に飽きて転職してしまわないよう、社内文化をどのように構築しているのかを紹介します。 開発者として、私は2年以上同じ仕事を続けた事がありません。 転職することは私にとって良いキャリアとなりました。私達の業界では転職を繰り返す事はごく一般的なことです。ところが、以前私が働いていた会社は、私の離職に難色をしめしました。中には、私を必死で引きとめようとする人もいました。しかし、私は仕事に飽きてしまっていたため、残ることはできませんでした。 (免責事項:私は多くのプログラマーよりも楽しいプログラミングの仕事をしていたと思います。仕事を変えることが常に最善の選択とは限りません。) 現在私はEnkiのco-founderで最高技術責任者(CTO)です。会社ではエンジニア文化の構築も行っています。

    こんなコーディングは退屈だ! | Yakst
    potato777
    potato777 2015/12/25
  • Redis作者自身によるRedisとMemcachedの比較 | Yakst

    Redisの作者antirez氏自らによる、memcachedとRedisの長所短所の比較。特に、Redisを単なるキャッシュ用アプリケーションとしてmemcachedと比較することの間違いと、それぞれの向いている使用方法についての私見。 あなたが私と面識があるなら、私が競合製品があることが悪いと考える人間でないことはご存知でしょう。ユーザーに選択肢があることは当にいいことだと思っていますし、だからこそ他の技術とRedisを比較するようなことはほとんどしませんでした。 しかし、最適なソリューションを選ぶためには、ユーザーは正しく情報を持たねばならないのも確かです。 この記事を書くのは、有名なライブラリであるSidekiqの作者として知られるMike Perhamが、Redisのバックエンドストレージとしての使い方を書いた記事を読んだのがきっかけです。従って、私はMikeがRedisに「反

    Redis作者自身によるRedisとMemcachedの比較 | Yakst
  • InnoDBにおける効果的な関数インデックス(MySQL Server Blogより) | Yakst

    MySQL 5.7では生成列の機能が追加され実体化されない仮想列を作成できるようになった。ユースケースとしては関数インデックスを効果的に利用すると、JSONなどをうまく扱える可能性がある。 免責事項 この記事はJimmy Yang氏によるMySQL Server Blogの投稿「JSON Labs Release: Effective Functional Indexes in InnoDB」(2015/4/9)をユーザが翻訳したものであり、Oracle公式の文書ではありません。 MySQL 5.7.6では、我々は生成列(Generated Columns)と呼ばれる新しい機能を追加した。最初の段階では全ての生成列は、仮想的なものであってもマテリアライズされていた。これでは不要なディスクスペースが使用され、ディスクI/Oが発生するだけでなく、いかなるテーブルの変更に対してもテーブルを完全に

    InnoDBにおける効果的な関数インデックス(MySQL Server Blogより) | Yakst
  • InnoDBの分離レベルによるMySQLのパフォーマンスへの影響 | Yakst

    MySQL Performance Blogの翻訳。MySQLがサポートする4つのトランザクション分離レベルの特徴とパフォーマンス上の特性を、トランザクション履歴の保持方法に的を当てて比較。 January 14, 2015 by Peter Zaitsev 過去数ヶ月に渡って、InnoDBのトランザクション履歴の負債の危険性と、MVCCがMySQLのパフォーマンス問題の原因になりうることについて、いくつかの記事を書いてきた。この記事ではそれに関連して、InnoDBのトランザクション分離レベルとMVCC(multi-version concurrency control、多版型同時実行制御)との関連性、そしてそれらがMySQLのパフォーマンスにどう影響するのかを取り上げてみようと思う。 MySQLのマニュアルにはMySQLでサポートされているトランザクション分離レベルの詳細な説明がある。こ

    InnoDBの分離レベルによるMySQLのパフォーマンスへの影響 | Yakst
  • 大規模環境でMySQLのGTIDを適用して得られた教訓 | Yakst

    MySQL 5.6からの機能であるGTIDを、Facebookの環境に適用した際の流れと主な不具合、そしてそれらの修正点について、Facebookのエンジニアによるまとめ。 by Evan Elias and Santosh Praneeth Banda Global Transaction ID (GTID)は、MySQL 5.6の新機能の中でも最も使わずにはいられない機能の一つだ。このおかげで、フェイルオーバやポイントインタイムリカバリ、階層を持ったレプリケーションなどに非常に有益だし、クラッシュセーフなマルチスレッドレプリケーションの必須条件にもなっている。この数ヶ月で、我々はFacebookの全ての番用MySQLインスタンスで、GTIDを有効にした。その中で、この機能の適用方法や操作について、たくさんの知見が得られた。たくさんのサーバサイドの修正事項については、WebScaleS

    大規模環境でMySQLのGTIDを適用して得られた教訓 | Yakst
  • 色んなログ、読む時間のある人いる? MariaDBのログ概要 | Yakst

    MariaDBプロジェクトの創設者Monty氏による、MariaDBおよびMySQLの各種ログの概要と設定についてのまとめ。 MariaDB 10.1の新機能を触っている時、(馬鹿げていると思うことの1つだが)一般ユーザはスロークエリログを無効にする方法が分からないのではないかと気づいた。 この機能を実装したりドキュメントを書いていて、色々なログの情報がバラバラになっていて、それらを有効にしたり無効にするのが意外と難しいのではないかとも思った。 これを解決するため、MariaDBのドキュメント(KB)に、MariaDBにもMySQLにも役立つだろうと思って「Overview of the MariaDB logs」というエントリを作った。 そのコピーがこの記事だ。コメントや追加して欲しい内容があれば、KBのエントリの方に意見を寄せて欲しい。たくさんの人の役に立つようにね! MariaDB

    potato777
    potato777 2014/08/12
    基本的に MySQL と変わらない。
  • [Q&A]MySQL開発でやってしまいがちな致命的ミス | Yakst

    Percona MySQL Webinarsの発表(MYSQL開発でやってしまいがちな致命的なミスについて)のQAをご紹介します。 発表はSQLアンチパターン著者のBill Karwinさんの発表です。 オリジナル: http://www.percona.com/resources/mysql-webinars/how-avoid-even-more-common-deadly-mysql-development-mistakes July 17, 2014 by Bill Karwin 水曜日に「MySQLを開発する上でよく起こる(そして致命的な)ミスをどのように回避するか」をPercona MySQL webinarsで発表した。お見逃の際は、ビデオとスライドを見る為に登録すればまだご覧にいただける。 参加いただいた皆様、そしてとりわけすばらしい質問をしていただきありがたく思っている

    [Q&A]MySQL開発でやってしまいがちな致命的ミス | Yakst
    potato777
    potato777 2014/08/11
    "SELECT *" はネットワーク負荷だけでなくディスク負荷にも影響。InnoDBのVarchar, Blob, Textなど 追加ページに格納している場合は不要なアクセスがでてしまうと。
  • Yakst - max_user_connectionsを設定して、MySQLのダウンタイムを回避しよう

    MySQL Performance Blogの翻訳。ユーザアカウントごとにコネクション数を制限できるmax_user_connectionsを利用して、コネクション数不足を回避する方法と、その利点について解説する。 July 29, 2014 by Peter Zaitsev MySQLのダウンタイム発生の、よくある原因の一つは、コネクション数が不足することだ。こんなエラーを見たことはないだろうか? ERROR 1040 (00000): Too many connections MySQLをある程度長く触っている人なら、間違いなく見たことがあるだろう。成功したトランザクションと失敗したトランザクションが混じって一時的に見えるエラーが発生したり、しっかり監視していない場合に限って、いくつかのプロセスが正常に実行されず色々なおかしな現象を引き起こしたり、なかなかに厄介なエラーだ。 コネクショ

    potato777
    potato777 2014/08/03
    "スクリプトやアカウントごとにユーザアカウントを使い分け、それぞれにリソース制限をかけるのだ。具体的には、max_user_connectionsを設定すればいい。"
  • Linuxで、どのプロセスがページングを行っているのか調べるには? | Yakst

    スワップがなぜ起きるか、どのようにスワップの状態を確認するべきかの平易な解説。Quoraの質問に対する、Robert Love氏の回答。 質問に対するストレートな回答は、調べるのは不可能、だ。どうしてそうなのかを説明してから、君の知りたい情報を含んでいるであろう、5つの関連する質問に答えよう。 Linuxのような、モダンなOSにおいては、スワップはシステム全体における現象だ。ある1つのプロセスがスワップに関する責任を持っているわけではない。システムがスワップしているかどうかは、メモリプレッシャの機能による。物理メモリを大量に使おうとすれば、スワップしてしまう。何をスワップアウトするかは、一番少ないページを要求しているのが何かによる。何をスワップインするかは、一番ページを必要としているのが何かによる。プロセスがRAM上に存在しないページを要求した時、そのページはディスク上にあるので、スワップ

    potato777
    potato777 2014/07/24
    調べることはできないとのこと。プロセス毎のスワップを調べるスクリプトを紹介している。
  • 結果整合性データベースのいま | Yakst

    一貫性モデルとして、結果整合性が利用されるデータベースに関して、現状の棚卸しをしているMariaDBプロジェクトの記事である。 各データベースの概要や、評判/成熟度/一貫性/ユースケースに基づいた評価、利点および欠点についてまとめた。 はじめに 結果整合性(eventually consistent) [1] は、多くの大規模分散データベースで使われる一貫性モデルの1つである。このようなデータベースでは、複製されたデータ片に対する全ての変更は 結果的に全ての関連するレプリカに反映される必要がある。 さらに、コンフリクトの解消はこれらのデータベースでは扱われず、更新のコンフリクトが発生した場合、アプリケーションで対処の責任を負う必要がある。 結果整合性は、弱い一貫性の1つの特異形態で、オブジェクトに新規の更新がない場合、ストレージシステムが全てのアクセスが結果的には、最後にアップデートした値

    結果整合性データベースのいま | Yakst
    potato777
    potato777 2014/07/23
  • MySQLとその仲間の過去・現在・未来 - MySQLの過去を振り返る Part 1 | Yakst

    長らくMySQLの開発に関わってきたStewart Smith氏が、MySQLの誕生から現在、将来の展望までを駆け足で語る。Part 1は、MySQLの始まりとMySQL AB社の創業、デュアルライセンスの採用まで。 linux.conf.au 2014での発表内容のビデオはこのURLから見られる(訳注 : この記事は、元々原文の筆者が発表したものを書き起こしたもの)。 ここではビデオではなくブログ記事としてこの内容についてみてみよう。 1979年、UNIREGというソフトウェアがあった。データベース(いや、テーブルか)に行を保存するためのテキストUIだ。UNIREGのことを出してきたのは、それがFoRMsという仕組みを使っていて、(MyISAMのディクショナリ情報を格納する)FRMファイルがその頭文字を使っているっぽいからだ。 1986年には、UNIREGはUNIXで動くようになった。そ

    potato777
    potato777 2014/03/03
    ざっくりMySQLの歴史。