2019年11月23日朝、QTnetのデータセンターで電源設備のトラブルが発生し、これの影響を受け同センター利用各社のサービスが利用できない等の障害が発生しました。（24日時点で完全復旧はしていない）影響を受けた企業の内、楽天カードでは朝からカードが利用できない等のシステム障害が発生しました。ここでは関連する情報をまとめます。 原因はQTnetの電気工事 2019年11月23日 [PDF] 【QTnet データセンター】データセンターシステムの障害による停止について 2019年11月25日 [PDF] データセンターの電源障害による停止について～2019 年 11 月 23 日発表「【QTnet データセンター】データセンターシステムの障害による停止について」の続報～ 2019年11月23日にQTnetはデータセンターで老朽化した電源設備更新のため取り替え工事（約10分間）を行っていた。*
はじめに Ruby on Rails界隈でよく耳にする「N+1問題」について解説します。 N+1問題を理解することで無駄なSQLの発行を抑え、処理時間の削減に繋げることができます。 ↓読んでほしい人 N+1問題を知らない人 Ruby on Rails初心者〜中級者 性能改善したい人 N+1問題とは ループ処理の中で都度SQLを発行してしまい、大量のSQLが発行されてパフォーマンスが低下してしまう問題のことです。 日常生活で例えるなら、スーパーで商品を1点ずつお会計するようなもの。 それだけ無駄なことを行なっている状態を指します。 え、そんなアホなこと普通はしないって思いますよね？ でもRailsを使用していると往往にしてこの問題が発生してしまうのです。 N+1問題の例 会社(companies)とそれに所属する人(users)を例に説明します。 例えばcompaniesテーブルとusers
ログ収集ツールとしてはFluentd、Logstash、Flume等が挙げられる。ファイルやメール、syslog、DB、センサからログデータを読込み、必要なログをフィルタして、jsonやxmlに整形してアウトプットする機能を持つ。 メリット プラグインが300+公開されており、様々な形式のデータをインプット、アウトプットできる 単体でログのフィルタ、バッファ、ルーティングができる 2000+を超える企業に利用されている 日本語の情報が多い デメリット 単体で動作するためfluentdが落ちたらバッファしているログが消える 想定外のログが入力されると大量のスタックトレースが吐かれる 引用：http://changineer.info/server/logging/fluentd-td-agent.html#fluentd-2 Logstash メリット フィルタを簡単にカスタマイズできる F
2019/05/16 更新しました。エラー検知ツールを紹介 ログ収集系の個人的な超簡易的なまとめです。 僕みたいなそんなの全然追っかけてないけど、運用監視のシステムを作る必要あったので最近のセオリーを調べないとな－っていう人向け。 既にもっと詳しいものはありますが、自分でまとめたかったのでまとめてみました。 とりあえずは有名どころの名前を羅列して最低限俯瞰できるようにしておきます。 ※内容間違っているとかあったら指摘ください。 エラー検知(エラートラッキング or エラーモニタリング)ツールについて 厳密にはログ収集と言ってはいけないかもしれませんが。。。 最近使い始めたのでおすすめしておきます。主にJavaScriptなどのフロントエンド向けですが、PHPやNode.jsなどのサーバーサイドもエラー検知可能です。 僕が今使っているのはSentryです。無料で十分使えて綺麗な管理画面もあっ
freee ではプロダクトの拡大に合わせて、汎用的な機能をマイクロサービスに切り出していこうとしています。すでにマイクロサービス化されているところは REST API による通信を行なっているのですが、これから新しく作るところはデフォルトで gRPC を採用しようとしています。 freee のサービスはすべて AWS 上で動いていますが、本格的に採用する前に gRPC アプリケーションを AWS で動かすときに注意することを調べてみました。 ALB では gRPC の HTTP/2 通信を負荷分散できない gRPC はデフォルトで HTTP/2 で通信します。 ALB (Application Load Balancer) は HTTP/2 に対応していますが、対応しているのはあくまでクライアントと ALB のフロントエンド側（リスナー）であり、ALB と EC2 のバックエンド側（ターゲ
いくつか調べてみました！ 優しめのマサカリください！！ ELBとは Elastic Load Balancer = ロードバランサー トラフィックの分散を行う サーバへのアクセスを、複数のアベイラビリティーゾーンの複数のEC2インスタンスに分散 全3種類 NLB - Network Load Balancer L4 NATロードバランサ TCPに対応 ALB - Application Load Balancer L7リバースプロキシ HTTP,HTTPSに対応 CLB - Classic Load Balancer L4/L7 リバースプロキシ TCP,SSL,HTTP,HTTPSに対応 特徴と違い 通信経路 ALB,CLBはリバースプロキシのため、行きも帰りもロードバランサを経由 NLBは宛先IPをクライアントのIPに変えるため、帰りはLBを通らない アクセス制限 ALB,CLBはポー
この記事はDMM.com #2 Advent Calendar 2017の14日目です。 はじめまして、普段はDMMサービスのシステム開発、保守を行なっている@norihです。 SPAの記事を書いておりますが業務的にはバックエンド側に触れることが多いエンジニアです。 今回は書くことは僕が2017年の初旬にリリースしたSPA（シングルページアプリケーション）の失敗談と、そこから学んだことについてです。 基本的なことかもしれませんがよろしくお願いします ほかのカレンダーURLはコチラです。 DMM.com #1 Advent Calendar 2017 DMM.com #2 Advent Calendar 2017 リリースしたSPAの概要 最初に今回リリースしたSPAについて少しだけ紹介させていただきます。 詳しいことは省略させていただきますが概要としては次のようなものです。 React +
サーバーサイドに比べて見落とされがちな、フロントエンドのエラーログ収集。JavaScriptのログ収集、確認に役立つ手法、ツール、ライブラリーを総まとめ。 開発進行中も本番モードでの運用時も、ソフトウェアアプリケーションにおいてロギングは大切です。 サーバーを運用しているなら、サーバーサイドの言語選択にかかわりなく無数のライブラリーを利用でき、広範に及ぶストレージメカニズムやログ出力を扱う際の各種ツールも使えます。 しかし、クライアント側アプリケーションとなるとロギングは見過ごされがちで、利用できる手法もかなり限られています。 この記事ではクライアント側アプリケーション、特にJavaScriptを中心としたシングルページアプリケーション（SPA）におけるロギングの実装方法を紹介します。 コンソール エラーとメッセージのロギング方法でもっとも一般的かつ分かりやすいのは、おそらくコンソールの使
はじめに Firebase Crashlytics を軽く試してみたのでまとめます。 組込先はAndroidアプリです。 ところでFirebase Crashlyticsって何だっけ 公式 によると次の通り。 Firebase Crashlytics は軽量なリアルタイムのクラッシュ レポート ツールで、アプリの 品質を低下させる安定性の問題を追跡し、優先順位を付け、修正するのに役立ちます。 これにより公開したアプリがエンドユーザー端末でクラッシュした際の解決の手がかりが得られます。 レポートは例えば次のような感じ。 Firebase Crash Reporting と Firebase Crashlytics と FabricのCrashlytics Firebaseは以前はクラッシュレポートツールとして Crash Reporting を提供していましたが、これは 非推奨となり代わりに
はじめに 2017年もあっという間でしたね！この記事はGoodpatch Advent Calendar 2017 – Qiitaの18日目です。 モバイルアプリケーションの仕様やデザインを決めていくうえで、エラーにどう対処するかは、PMやデザイナーから見落とされがちです。エンジニア視点でも、どう対処すべきか迷いながらコードを書くことは多いのではないでしょうか。 この記事では、モバイルアプリケーションをつくる際に、どのようなエラーが発生しうるのか、それらにどう対処すべきなのか、全体像が俯瞰できるようにエラーを分類しながら、私個人の考えをまとめます。 Swiftのエラー4分類（参考：Swiftのエラー4分類が素晴らしすぎるのでみんなに知ってほしい – Qiita）はすばらしいのですが、これでもまだどれに分類されるのか判断が難しいと感じたので、よりわかりやすい分類を試みてみました。 エラーが発
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 今開発しているPlayer!で、チャット系のリアルタイム更新処理が必要となったので、色々調べています。 ※「スマフォアプリ」として共通事項が多いのでそう表記しましたが、基本的にスマフォアプリはiOSアプリとして書いてます。Android・Windows Phoneなどは差異があったり読み替える必要があると思っています。 結論 後半で詳しく書きますが、今のところ以下の結論に至りました。 PUSH通知に全て依存する構成でもそれなりに動く PUSH通知 + 双方向通信処理(WebSocketなど)の併用がベスト 双方向通信処理はPusher・
Lobiチームの長田です。 今回はLobiの根幹であるチャットサービスの、Streaming APIについて紹介します。 多くのチャットサービスがそうであるように、 Lobiでも新しいチャットメッセージが画面リロードの必要なく表示されるようになっています。 チャットメッセージをデータストリームとしてクライアントに送信するためのAPIがStreaming APIです。 LobiのチャットサービスはiOS・Android・Webブラウザで利用することができ、 これら全てでStreaming APIを使ったチャット画面の自動更新を実現しています。 即時反映の実装方法としては Polling Long Polling Web Socket など複数の方法が挙げられますが、LobiではHTTPリクエストのLong Pollingをベースにした 独自のフォーマットを使用しています。 仕組み app -
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
