AWS DEV DAY 2018 https://aws.amazon.com/jp/aws-devday-tokyo-2018/sessions/#sm06
研究開発部の染谷 ( @ayemos_y ) です。好きな ImageNet のラベル(Synset)は "Eccentric, eccentric person, flake, oddball, geek" です。 クックパッドの研究開発部は2016年7月に発足し、現在はアルバイトを含め13名の体制となっています。その中で、こちらの記事でも紹介されている料理/非料理判別モデルを開発するなど、機械学習/ディープラーニング分野に特に力を入れて取り組んでいます。 最近は、モデルを開発し改善する手法などについて多くの情報にアクセス出来るようになり、このような技術をプロダクトに応用していきたいという気持ちが高まっている現場が多いかと思います。しかし一方で、分析の為のデータへのアクセスや画像認識モデルの実装や実験を行うためのGPU環境の整備など、現場の都合に対応するコストによって開発の勢いが鈍化して
こんにちは、技術部の Taiki (@taiki45) です。 近年の Web サービスの開発ではマイクロサービスに代表されるように分散アーキテクチャが採用されるようになってきました。大規模でも素早いプロダクト開発をするために、クックパッドでもマイクロサービスを採用し分散アーキテクチャへの移行を進めています*1。今回は、そのような分散アーキテクチャを利用したシステム構築において必須のコンポーネントになりつつある分散トレーシングについて、クックパッドでの事例を紹介したいと思います。 分散トレーシングとは マイクロサービスのような分散アーキテクチャでは、個々のサービス同士の通信が複雑になるため、モノリシックアーキテクチャと比較して、システム全体としての振る舞いを把握することが難しくなります。これはプロダクト開発においては、障害発生時の原因究明が難しくなったり、あるいはシステム全体でのパフォーマ
こんにちは。牧本 (@makimoto) です。最近はバックエンドシステムの設計をやったりしています。 今回は複数のサービスが存在するとき、その間でどのようにデータ連携を実現するかついて述べていきます。 背景と問題定義 cookpad.com は世界有数の規模の Ruby on Rails で作られたウェブアプリケーションです。 巨大な Rails アプリケーションは単純に起動やデプロイ、テストが遅いという問題以上に、自分の変更が与える影響範囲を予測するのが困難という大きな問題があります。cookpad のメインレポジトリ (cookpad_all と呼ばれる) には1つの mountable engine を共有する Rails アプリケーションは7つがあり、困難さに拍車をかけています。cookpad_all を触る開発者は新しい機能を追加する、既存の機能に手を入れる、不用な機能を消すな
インフラストラクチャー部の成田です。2015年10月現在、インフラストラクチャー部には私を含め7人のインフラエンジニアが所属しており、このメンバーでクックパッド本体サービスをはじめ様々な新規事業やいくつかの子会社のサーバを運用しています。私自身もエンジニアではありますが部のマネージャも兼ねているため、立場上、社外の方からインフラエンジニアのマネジメントについて質問されることがよくあります。今回は、私自身の考え方とクックパッド社における事例を紹介したいと思います。 「インフラエンジニア」とは 「インフラエンジニア」という言葉の定義はあいまいで、しばしば議論の的になります。傍目からは明らかにインフラエンジニアであるように見えるにも関わらず「私はインフラエンジニアでは無い」と主張する人たちもいます。このような状況になっているのは、サーバ運用に関する業務分掌が会社ごとに異なるからであると私は考えて
こんにちは。インフラストラクチャー部の加藤(@EugeneK)です。 今回はWebサービスを運用する上で欠かせない、モニタリングをクックパッドでどうしているかという話をします。 死活監視と性能監視 Webサービスを運用している以上、そのサービスを稼働しているサーバがあり、サーバには故障やトラブルが発生します。 また、どれくらいのパフォーマンスが出ているか、リソースをどのくらい消費しているかなどのトレンドを把握することは、成長するサービスを支えていく上で欠かせません。 故障やトラブルにいち早く気づくための仕組みを死活監視と言います。 また、サーバリソースの時系列での推移を知るために、グラフとしてトレンドを可視化する仕組みを性能監視と言います。 ポーリング監視の限界とZabbixのアクティブ監視 クックパッドでは死活監視にNagios、性能監視にMuninを使用してきましたが、サーバ台数の増加
技術部 id:sora_h です。今回は v2 より AWS 上での運用に対応した GitHub Enterprise を、オフィスにある既存の環境から AWS へスムーズに移行した話について説明します。 GitHub Enterprise v2 GitHub Enterprise (以下 GHE) とは、github.com を自前の環境で運用できるアプライアンスです。クックパッドでは主に GHE 上で開発を行っています。 従来まで GHE の実行環境として VMware vSphere, VirtualBox 上の実行しかサポートされていませんでしたが、11 月にリリースされたアップデート v2 より、AWS での実行がサポートされました。 クックパッドでは全面的に AWS を利用していますが、いままで GHE を AWS 上で動作させる事はできませんでした。そのため、オフィス内に E
インフラストラクチャー部 星野(@con_mame)です。 少し前から、一部レシピページに料理動画を掲載していました。当初はYoutubeを使用していましたが、本日から自社配信に切り替わりました。現在はまだ掲載数は少ないですが、今後掲載数を増やしていきたいと考えております。 そこで、今回は、動画配信プラットフォームの裏側がどうなっているかという点を簡単にですがご紹介したいと思います。 構成図 構成図を見ていただくのが一番わかり易いと思うので、最初に掲載します。 見て分かる通り、今回は全てAWSのサービスを使用して構築しています。 今回使用したサービスは エンコード: Elastic Transcoder データストア: DynamoDB + DynamicDynamoDB ストレージ・配信: S3 + CloudFront エンコード通知など: SNS 今回、構築までの期間とエンコードや動
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く