はじめまして。柴田です。
いろんなスケジュールが重なってしまい、
前回の記事からまた間があいてしまいました。
今後は定期的に更新していければ良いですね。
さて、当社が運営しているウェブサイト「ショッピングサーチ.jp」では
各ECサイトを巡回して、商品画像を取得しています。
今回、縮小画像の画質向上、商品数増加に伴う回収スピードの向上が必要となったため、
回収・加工システムをリプレイスすることになりました。
大まかな処理として以下の2つがあります。
イメージにするとこんな感じです。
各ECサイトに取りに行った画像を加工するという流れです。
お初にお目にかかります。
コマースリンク システム部の栗原と申します。
業務では主に運用を担当しております。よろしくお願いいたします。
今回は技術の話はお休みして、先日参加してまいりました【 エンジニアサポート新年会2012 CROSS 】のレポートをしたいと思います。
本イベントは、ニフティが主催しているWEB技術の勉強会です。
■公式サイト
エンジニアサポート新年会2012 CROSS
※各セッションの動画がUPされていますので、ご参照ください。
参加者の基本的な行動としては、スマートフォン、クラウド、次世代LAMP、データマイニング等のテーマの中から、興味のあるセッションを聞きにいくわけですが、エントランスにはお酒、食事も用意されているので、他の参加者の方と歓談したり、情報共有したりと楽しみ方も人それぞれ。
セッションにおいても、講演者のプライベートな開発環境の話や、新技術導入時どう上司を口説くか？などの雑談も交え、勉強会というよりも、夏フェス？の様な雰囲気で会場は終始盛り上がっておりました。
当の私はというと、セッションの拝聴に精を出していたわけですが、終盤にメインブースでも発表され、「2012年盛り上がる技術」第2位にノミネートされた『Node.js』、（※ちなみに1位は『HTML5』）オブジェクト指向DBの『MongoDB』の最新事情にうつつを抜かしていました。
■下記セッションで詳しく解説されておりました。
セミナーセッション 次世代LAMP CROSS
『Node.js』については、サーバサイドでJavaScriptが使える利点に加え、非同期のアーキテクチャを活かしたバッチの並行処理の管理なんかにも威力を発揮するとか。Web上にもたくさんの記事が出ていますし、「Cloud9 IDE」などのIDEもあるので、学習もしやすいのかと思います。『MongoDB』は当社でもプロダクションに採用しており、検索エンジンのインデックスを作成するため商品データを格納しています。
エンジニアサポート新年会、来年も開催予定とのことですのでご興味ある方は来年是非足を運んでみてください。
ちなみに私まだ3年目のペーペーエンジニアなのですが、ものの見事に感化されて帰ってまいりました。新人のモチベーション低下にお悩みの方いらっしゃれば、勉強会確実にお勧めです！
以上栗原がお届けしました。
次回は技術のトピックを予定してますのでお楽しみに！
初めまして、akuta です。
前回の記事から間があいてしまい息をしているの？と一部の方にご心配を
かけてしまい申し訳ありません。いろいろ事情が重なりましたが、
今後は定期的に更新していきたいと思いますのでよろしくお願いいたします。
さてそのいろいろな事情の１つとして、サービスを行なっていく上で
避けて通れない障害があります。今回はその障害の切り分け方法について
書いておきたいと思います。
障害 の切り分け方法はいくつかあると思いますが、プログミングに強くない
私はパケットによる調査をよく使います。
具体的には、先日発生した開発中の外部サービスとの連携に関する障害を使って
説明します。
この連携では外部にhttpで要求を投げて、そのレスポンスを受け取るという
非常に単純なものですが、何故か不特定に失敗する障害が発生しました。
他のサーバでテストしてみると正常に動作するため、プログラムの問題というより
サーバ固有の問題ということで、ひとまずパケットを見てみることにしました。
まずはtcpdumpでhttp要求を取得して、Wiresharkで見てみます。
tcpdump -i eth0 -s 4096 -w hoge.log
キャプチャーしつつ、連携コマンドを流しエラーが発生するの待ちます。
待つこと数分でエラーが発生したので、しばらく放置してからキャプチャー終了。
そしてwiresharkで確認。キャプチャーが大きくなりすぎると、パソコンの負荷が
高くなってしまいますが、そこはガマンして一つ一つ見ていきます。
しかしエラー発生時のパケットは正常なものばかり、、、、というか
エラー時にはhttpリクエストすら発行されていない。アプリのバグかよ～という
思いもよぎりましたが、ここは冷静になってhttp以外のパケットも全部とって
みることにしました。
tcpdumpで待ち構えて、コマンド流し続けて待つこと数分。
エラーが発生したので、様子を見てからキャプチャー終了。
気が重くなるようなログサイズのキャプチャーファイルをwiresharkで
開き、エラー発生時間のパケットを丹念に見ていくと、どうもDNSへの
要求が正常に返せていないのでは？と気づきました。
そして再度DNSのパケットだけ取得して数分待ち、再びwireshark。
それまで query => response , query => response と要求を返していた
DNSが突如 responceを返さなくなります。
なんだよDNSかよ～と結論づけようとしましたが、他のサーバも同じDNSを
使っており問題は発生していないので、DNS自体に問題はないと思い、
続いてネットワークボード関連を疑うことに。DNSはhttpとは異なるNWボードを
使っていたので、pingフラッドで状況確認。
# ping -f xxx.xxx.xxx.xxx PING xxx.xxx.xxx.xxx (xxx.xxx.xxx.xxx) 56(84) bytes of data. --- xxx.xxx.xxx.xxx ping statistics --- 2991 packets transmitted, 2991 received, 0% packet loss, time 34874ms rtt min/avg/max/mdev = 0.126/32.247/717.828/119.466 ms, pipe 60, ipg/ewma 11.663/92.585 ms
近くのサーバに対して実行してみた結果ですが、packet lossはしていないものの、
avrgやmax値が明らかに大きすぎる値となりました。通常avrg : 0.24程度。
ということで、ネットワークボードと対向のスイッチポート、LANケーブルを
別途調査することにして調査はひとまず終了。
「かわいい女のコだと思った？残念さやかちゃんでした！」という名言が示唆するように、
アプリ障害だと思った？残念NW障害でした！という事例もあるので、
原因を決め付けず、パケットも見ておいたほうがよいですねというお話でした。
iframe版Facebookアプリをユーザーが表示した際にはsigned_requestというパラメータがPOSTで渡されてきます。
Signed Request https://developers.facebook.com/docs/authentication/signed_request/
公式ページ（上記）に詳細に書かれていますが、ざっくり言うとsignature（Facebookの署名）と実際のJSONデータが「.」で繋がれて渡されてきます。
このsignatureを「アプリの秘訣」を使って評価することで、Facebookからの正当なアクセスかどうかを確認することができます。
で、公式ページや世間一般にはPHPのコードはたくさんあるのですが、Perlのサンプルや解説があまりなかったので簡単に紹介します。
まず、signatureもJSONデータもbase64urlでエンコードされてます。
MIME::Base64::URLSafeというモジュールがCPANに登録されていますのでそれを使うのが簡単ですが、base64とbase64urlは「+」「/」がそれぞれ「-」「_」になるだけの違いなので、通常のMIME::Base64を使っても簡単に処理できます。
こんにちは！
コマースリンク システム部の小松です。
コマースリンクでは商品検索サイトの「ショッピングサーチ.jp」を中心に、いろいろなECサービスを展開しています。
商品検索に関する技術をはじめとして、アプリケーションやインフラで活用している技術やテクニックから、アクセス解析などのWebの運営に関する話など、弊社エンジニアが取り扱っている内容を幅広く取りあげていきたいと思っています。
皆さんのお役に立てる記事が書けるかわかりませんが、今後ともよろしくお願いいたします！
