3: Fluentd, Rails, ActiveRecord - Admins Bar
DeNA の @sonots さんと @ryopeko さんに、 Fluentd や Rails 、特に ActiveRecord まわりの運用ノウハウについてお聞きしました。Perl ヘビーユーザーとして有名な DeNA さんですが、 Perl エコシステムの知見が Ruby でのサービス開発・運用に生かされているお話はとても興味深かったです。 Show Notes “2万行の conf” うちの fluentd.conf は２万行あるぞ — そのっつ (SEO Naotoshi) (@sonots) September 27, 2013 Shadow Server on Fluentd at Fluentd Casual Talks #3 DeNA での Fluentd の運用規模、クラスタ構成についての記述がある sonots/haikanko HaikankoというFluentdク
大量データをスムーズに処理 失敗しないバッチ処理のアーキテクチャ設計、5つのポイント
バッチ処理とは 前回はWebアプリのアーキテクチャ設計の基礎を解説しました。今回はバッチ処理を円滑に行うためのアーキテクチャ設計のポイントを紹介します。 バッチ処理とは、蓄積された複数件のデータを、まとめて一括処理する処理形態のことを指します。このような処理形態においては、大量データの処理を一定時間以内に完了させるためのアーキテクチャを、さまざまな角度から検討していく必要があります。 また、画面オンライン処理とは異なり、ユーザーとの対話なく処理が進められます。よって、バッチ処理の途中でエラーが発生した場合の対応を考慮して、アーキテクチャを設計しなければなりません。バッチ処理の基本についてより深く知りたい方は、下記参考記事をご参照ください。 参考リンク:鉄板焼のお店から学ぶ、バッチ処理"超"入門（＠IT） バッチ処理におけるアーキテクチャ設計時の検討ポイント バッチ処理のアーキテクチャを考え
決済サービスを使う上で注意すべきこと - ボクココ
今回、CtoCサービスの決済で Webpay を利用しました。 これは便利！と思いながらゴリゴリ開発を進めていって、後は商業用のAPIキーさえ発行されれば終了だ！と意気揚々と商業申請。 そしたら10日以上の時間をかけて結果は「審査落ち」。最後はこんな一言で締めくくられました。 この度はWebPayにご興味を持って頂き、誠にありがとうございました。 自分のWebpay用のシステム開発の時間が水の泡となりました。ここから得られた教訓は一つ。 審査にひっかかりそうなサービスの場合は開発する前に商用申請する これに尽きます。 ただ他のサービスを色々調べてみたら意外な誤算が。ななななんと、 Yahoo Fastpay も Spike もだいたい同じ決済のAPIでした。おそらく共通のOSSを使っているんでしょうね。webpayのgemとかもStripeのとほとんど同じみたいだし。まぁそんなもんか。 今
クレカ決済の審査時に『特定商取引法に基づく表示』のこんなところを見てます | WebPay運営者ブログ
この投稿はWebPay Advent Calendar 2013の15日目の記事です。 14日目: 今からでも遅くないWebpay入門 16日目: 少しのコードでWebPayを導入する Python Ver. 特商法記載がないとネットビジネスができません ウェブサービスやモバイルアプリなどのオンラインでビジネスをする際には、必ず『特定商取引法に基づく表示』を適切に行わなければなりません。これに違反すると100万円以下の罰金か最悪の場合だと業務停止命令の対象となることもあります。 そういったこともあり、クレジットカード決済を導入する際には、カード会社の審査において、申請のあったウェブサービスやモバイルアプリ内において特定商取引法に基づく表示がきちんとなされているかどうかしっかりとチェックされます。 ただ、何を記載したら良いのかとてもわかりにくく、経済産業省が用意した公式のQ&Aもありますが、
暗黒の激安MVNO回線 激遅 b-mobile 考察 - Acer aspire one 533-kk11
長くイオンSIM使っていたんですが、同じ料金でプランNへ変更出来るようなので変更してみました。試しに(遅いけど)ガンガン使ったわけです。ところが全く速度が出ない。というより通信出来ない。 調べてみました。これ、速度規制があるんですね。最低限200kbpsと思っていたら、規制食らうと2kbpsとか冗談のような世界になります。タイムアウトさせてパケット叩き殺してくる。この速度では規制というより遮断です。 tcp/ip通信プロトコルではエラー時に再送を行ないます。ところがこの再送が叩き殺される。結果、文字化けやタグ解釈不能になって、ブラウザでの表示がメチャクチャになります。通常の通信ではありえない現象です。 まさに大昔(音響カプラー)の無手順通信。30年くらい前の2.4kbpsのMNPモデムはエラー訂正とデータ圧縮してくれていたから、それ以下の通信品質です。 当然ながら通信機器にも過剰な負荷が発
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
