Cookpad の新規事業と Firebase - クックパッド開発者ブログ
国内事業開発部 iOS エンジニアの三浦です。私は17年新卒で入社したのですが、それ以来複数の新規事業の開発に携わってきました。 現在開発中のアプリでは、バックエンドに Firebase を用いた開発を進めています。 この記事ではなぜ Firebase を使っているのかと、そこで得られた知見についてまとめようと思います。 なぜ Firebase みなさんご存知かと思いますが、Cookpad のレシピサービスでは主にバックエンドに AWS と Ruby on Rails が使われています。 なぜ新規事業ではその構成ではなく Firebase を使うのかということですが、以下のような理由があります。 基盤サービスが豊富 Firebase には RealtimeDatabase、FireStore といった Database を始めとして、CloudMessaging(Push通知基盤)、Aut
サーバーレスがアプリケーションにもたらす本当のメリットとは？「サーバーレスのポテンシャルとシステム表現」#devsumi ｜ Developers.IO
サーバーレスがアプリケーションにもたらす本当のメリットとは？「サーバーレスのポテンシャルとシステム表現」 #devsumi 「そのサーバーレス、本当に意味あるの？」 AWS re:Invent 2014で、AWS Lambdaが発表されてから丸3年が経過。サーバーレスという単語もすっかりこの界隈では定着した感はあります。 ですが、実際の開発・運用ノウハウについては、まだまだ試行錯誤が続いているのが現状じゃないでしょうか。ぶっちゃけ、既存アプリケーションのEC2をLambdaに置き換えるだけではほとんどメリット無いでしょ、という感触は、ある程度サーバーレスアプリケーションをゴリゴリ作っている人であれば、よく感じていることだと思います。 そんななか今回受講したこのデブサミのセッションでは、新しい観点でサーバーレスがもたらす恩恵やメリットを捉えることができてごっつ新鮮だったので、その模様をお届け
ソリューションアーキテクトという仕事について - 工場長のブログ
ex-mixi Advent Calander 2017の12/12分のポストです。みんなエモいことを書いているのでわたしもエモいことを書くことにします。 ちなみに今日はわたしの結婚記念日で、嫁とはmixiで出会いました（物理/社内）。 で、テーマはソリューションアーキテクト（以下、SAと略します）という仕事について。もっとみんなにSAって何なのかというのを知ってもらいたいなと思ってます。SAってめっちゃ面白いよ！ってのを叫びたいのです。なお、本ポストではわたしがAWSでSAをやっていたときの話をしますが、あくまで経験や「わたしはこうやっていた」という話であって、AWSを代表する見解ではないことをご理解ください。 mixiには2010/2から2012/7までの約2.5年在籍していて、ずっと広告関連のアプリケーション開発をやっていました。自分のなかではものすごく体感時間長かったんですが、振り
AWS FargateとLambdaでサーバーレスなクローラー運用 - orangain flavor
これはWebスクレイピング Advent Calendar 2017の7日目の記事です。こんな感じでAWS FargateとAWS Lambdaを使ってサーバーレス（EC2レス）なクローラーを作ります。 この記事はFargateでのクローリング処理にフォーカスしており、クロールしたHTMLをS3に保存するところまでを主に解説します。Lambdaの方はおまけ程度の扱いで、スクレイピングしたデータの扱い（データベースへの格納など）はスコープ外です。 長くなったので目次です。 背景 AWS Fargateの登場 クローラーの構成 やってみる 1. ScrapyのプロジェクトでSpiderを作る 2. Scrapy S3 Pipelineをインストールする 3. Scrapy S3 Pipelineをプロジェクトに追加する 4. ScrapyのプロジェクトをDockerizeする 5. Amazo
AWSの新サービス群に対する一行所感 - プログラマでありたい
今年もラスベガスで、AWSの最大のイベントre:Invent開催中です。初回のキーノートが終わった所ですが、怒涛のサービス発表で頭が混乱中です。整理のために、サービスに対する感想をつけてみます。間違っているかもしれないので、悪しからず。 AWS AppSync モバイル等での複数端末のデータ同期を見据えたソリューション。必要性はすごく解るが、それってCognito Syncでやりたかったことじゃないのかな？認証認可のサービスにデータ同期を加えた筋の悪さを解消に来たのか？ 2017/12/3 追記 中の人曰く、次のような役割分担とのこと AWSの新サービス群に対する一行所感 - プログラマでありたい ありがたし / Cognito Syncは「一つのIdentityに（≒一人の人間）が持つ」複数端末間での設定値等の同期のためのものだったので、前提と志向が違うのです > AppSync “それ
Java プログラムでホスト名の名前解決ができなくなる原因。JVM の DNS キャッシュの仕組みと、キャッシュの有効期間を変更する方法 - Qiita
Java プログラムでホスト名の名前解決ができなくなる原因。JVM の DNS キャッシュの仕組みと、キャッシュの有効期間を変更する方法Java JVM は ホスト名を解決すると IP アドレスをキャッシュします。 発生する問題 あるサーバのホスト名が変化しなくても、IP アドレスが変わると、 Java のプログラムからそのサーバにアクセスできなくなることがあります。 具体的には、 AWS の ELB はホスト名が変わらずに IP アドレスだけ勝手に変化することがあるので、そのような場合に、名前解決に失敗します。 もちろんサーバ側の管理者が DNS の A レコードを変更したときにも発生するので、 AWS のみならず一般的に起き得ます。 どのようにキャッシュしている？ キャッシュを保持してある場所 InetAddress クラスがキャッシュを保持しています。 キャッシュが存在する限り、名前
コンテンツキャッシュとVaryヘッダとnginx - Qiita
Varyヘッダは前段のキャッシュサーバに対して、指定したヘッダの内容ごとにキャッシュを分ける必要があることを伝えるためのものです。例えばサーバがVary: Accept-Encodingをレスポンスヘッダに付加しておくと、キャッシュサーバはAccept-Encodingヘッダの内容に応じたキャッシュを保持します。 こうすることでクライアントのAccept-Encodingヘッダの内容に応じたキャッシュデータをキャッシュサーバは返すことができるというわけです。 nginxにおけるgzip圧縮とVaryヘッダ さて、本題です。上記のような事情からかApacheのmod_deflateやh2oなんかはコンテンツのgzip圧縮を有効にすると、自動的にVary: Accept-Encodingをレスポンスヘッダに付加します。一方我らがnginxは設定ファイルにgzip_vary on;と書かないとV
» アダルトサイトをAWSで運用する時に信頼性と料金節約を両立する為のノウハウ | アダルトサイト制作会社
弊社で大規模なアダルトサイトの運用を行う上でのAWS利用構成を紹介させて頂きます。 利用料金を抑えたいというビジネス的な観点と、サービスを止めない為の障害回避を念頭に構成を紹介します。 関連：AWSのt2.microで月間100万PVに耐えるアダルトサイトを制作した話 この記事は技術者向けの内容になっています。 システム開発の発注をお考えの方は、こちらアダルトホームページ制作のご案内をご覧下さい。 サービスを止めない為のAWS利用構成 サービスを止めない事は弊社では2つの思想によって設計をしております。 障害を防ぐ為の堅牢な設計とする 障害が起きた時に瞬時に復旧、あるいは回避する 前者はイメージしやすいと思いますが、弊社では後者のフェイルオーバーも非常に大事であると考えています。 システム障害が起きない様にスペックを十分に確保する等は当然の事ですが、 万が一障害が発生した場合に即座に代替機
Amazon API GatewayでAPIキー認証を設定する | DevelopersIO
ども、大瀧です。 AWS Summit NewYorkで発表&リリースされたAmazon API Gatewayをいろいろ触っています。API Gatewayの機能の一つとして、認証機構の追加があります。今回はAPI Gatewayがサポートする認証の一つとして、APIキー認証を紹介してみます。 APIキー認証とは API GatewayのAPIキー認証は非常にシンプルで、所定のキー(文字列)を所定HTTPヘッダ(x-api-keyヘッダ)に含めたリクエストであればアクセス許可、無ければアクセス拒否とする機能です。 APIキーは、API Gatewayで生成・管理されるようになっており、セキュアな運用が可能です。 前提の構成 以下の記事のセットアップが完了している状態です。 Amazon API Gateway – API作成から動作確認までやってみる ｜ Developers.IO gr
なぜAWS LambdaとRDBMSの相性が悪いかを簡単に説明する - Sweet Escape
2020/01/20 Update: 本エントリの内容は2019年12月3日にアナウンスされた『Amazon RDS Proxy』のリリースにより完全に陳腐化しました。過去のアンチパターンがフィードバックをもとにした改善によってアンチパターンではなくなるという最高の事例です。 サーバーレス元年始まった！ 今年がサーバーレス元年な理由. それはLambdaに以下が揃ったから. ・カスタムランタイムで実質どんな言語でも利用可能 ・VPC利用時のコールドスタート改善 ・Provisioned Concurrencyでスパイク対応も可能 ・RDS ProxyでRDBとの接続が現実的に これまで5年で受けたフィードバックがついに結実. 強い— Keisuke Nishitani (@Keisuke69) 2020年1月19日 RDS Proxyの詳細はこちらからどうぞ。まだプレビューですがぜひ試して
RDSのフェイルオーバーとJDBCコネクションプーリングでハマった件 - なからなLife
フェイルオーバー発生させたら、15分固まった。 Amazon RDS MySQL 5.6.23＋Tomcat＋JavaServlet＋Connector/Jでコネクションプールを利用した環境で、RDSのフェイルオーバー試験をするべくManagement Consoleから「Reboot with Failover」を発生させたら、フェイルオーバーは数分で完了して他の新規接続も受け付けられているのに、前から接続していた分が固まってしまいました。 フェイルオーバーが始まった直後に投げたリクエストのあと、うんともすんとも言わない。 JDBCのconnectTimeoutは3秒にしてあって、SecurityGroupの設定ミスなどでつながらない場合は5秒でタイムアウトすることは確認済みなのに、このケースではお返事が帰ってこない。。。 ぐぐっても、新規接続時のタイムアウト（connectTimeou
【資料公開】AWS Summit Tokyo 2017にてDMMのAWS移行について紹介してきました - DMM.comラボエンジニアブログ
2017 - 06 - 02 【資料公開】AWS Summit Tokyo 2017にてDMMのAWS移行について紹介してきました Tweet Share on Tumblr 本日AWSSummitにて岩崎、飯田、西村の3名が登壇して来ました！ 『DMMにおける会員基盤プラットフォームへのAWS導入から活用事例の紹介』 と言うタイトルでお話をさせていただきました。 導入時期が特段早かったという訳ではないですが、 開始してからはかなりのスピード感で移行を行うことが出来たと考えております。 内製DMM API GatewayのAWS移行で特にお伝えしたいポイントは４点 ・オンプレミスのミドルウェア⇒AWSのマネージドサービスの置換 ・EC2パラメータストアによるシークレット値管理 ・ElastiCache Redis Clusterの選定理由 ・Multi-AZ構成環境下のシステム統
Amazon ECSを用いたDocker本番運用の実現 - Qiita
はじめに 現在お手伝いしているアカウンティング・サース・ジャパンにて、ECSを使ったDockerの本番運用を始めたので、その一連の流れについてまとめました。 税理士向け会計システムを扱うアカウンティング・サース・ジャパンでは最近Scalaでの新規プロジェクトが立ち上がってきており、既存のプロジェクトはJavaであったり、Erlangであったりと様々な言語が用いられていますが、インフラ人員が少ないということもあり、なるべくシンプルなインフラ構成を実現する必要がありました。 そういった中、各アプリケーションをDocker化することでインフラとしては共通基盤としてのDockerクラスタのみの管理になり、運用コストが下がるのではないかという仮説からDocker化を進めることになりました。クラスタを実現するに辺りKubenatesなどの選択肢もありましたが、今回はECSを選択し、下記のようにAWSの
Elixir deployments on AWS
If you spend any time around the Elixir community, it won’t be long before you come across mention of the state of deployments. As things stand at the start of 2017, they are a little on the rough side: My biggest issue with Elixir is that it’s hard to set up a proper CI/Deployment pipeline. It CAN be done and I’ve done it but nothing “just works” like it does with Node. Try dockerizing a phoenix
最近のサービス間のデータとイベントの連携について - クックパッド開発者ブログ
こんにちは。牧本 (@makimoto) です。最近はバックエンドシステムの設計をやったりしています。 今回は複数のサービスが存在するとき、その間でどのようにデータ連携を実現するかついて述べていきます。 背景と問題定義 cookpad.com は世界有数の規模の Ruby on Rails で作られたウェブアプリケーションです。 巨大な Rails アプリケーションは単純に起動やデプロイ、テストが遅いという問題以上に、自分の変更が与える影響範囲を予測するのが困難という大きな問題があります。cookpad のメインレポジトリ (cookpad_all と呼ばれる) には1つの mountable engine を共有する Rails アプリケーションは7つがあり、困難さに拍車をかけています。cookpad_all を触る開発者は新しい機能を追加する、既存の機能に手を入れる、不用な機能を消すな
AWS 導入事例：任天堂株式会社、株式会社ディー・エヌ・エー| AWS
Super Mario Run の配信を開始した当日は、待ちわびた世界中のユーザーからのアクセスが一気に集中しましたが、AWS のインフラは十分なレスポンスを返し続けてくれました。ここまで何も大きな障害が発生しないケースは、大量のアクセスが想定されるゲームの配信開始時では極めてまれなことですし、2017 年 3 月時点で 8,000 万ダウンロードを突破する規模になっても AWS で特に問題は起こっていません。 任天堂株式会社は「任天堂に関わる全ての人を笑顔にする」ことを目指し、ホームエンターテインメント分野において、世界中のユーザーにかつて経験したことのない楽しさ、面白さ、驚きを持った娯楽を提供することを最も重視しています。任天堂ではこれまで、ホームエンターテインメントのビジネスを主にゲーム専用機の提供で推進してきました。 さらに任天堂では、先進国が中心となっているゲーム専用機の利用者に
AWS と EU の一般データ保護規則 (GDPR) | Amazon Web Services
Amazon Web Services ブログ AWS と EU の一般データ保護規則 (GDPR) ちょうど 1 年ほど前、欧州委員会は新しい「EU一般データ保護規則」（General Data Protection Regulation, GDPR）を承認し、採択しました。ヨーロッパにおけるデータ保護についての法律において、GDPR は 1995 年に導入された「EUデータ保護指令」（「指令 95/46/EC」とも知られている) 以来の大きな変化です。GDPR は EU における個人データ（personal data）のセキュリティや保護を強化を目指しており、EUデータ保護指令や関連する全ての特定地域の法律を置き換えます。 AWS は GDPR の制定を歓迎します。この新しい強固な要件はデータの保護、セキュリティ、コンプライアンスの基準を引き上げ、最も厳しい統制に従うよう産業界を後押し
I am mitsuruog | AngularJSで作ったSPAをAWS上の「S3＋CloudFront」でお手軽ホスティングして、クラウドサービスってやっぱ素晴らしいなと思った話
AngularJSで作ったSPAをAWS上の「S3＋CloudFront」でお手軽ホスティングして、クラウドサービスってやっぱ素晴らしいなと思った話 最近は、WebAPI や AWS のようなクラウドサービスが普及してきて、バックエンドのサーバーがなくても、Web サービスが公開できるようになってきました。 今回は AWS のS3 にある Static Website Hosting 機能を使って AngularJS で作成した SPA(Single page application)をホスティングさせてみました。 割と S3 でのサイト公開は簡単なので楽勝かと思いきや・・・ いろいろまじめに考えると手こずるものですね。 S3 での SPA 公開 S3 でのサイト公開は非常に簡単です。次の 3 ステップで即公開できます。 (「S3 サイト公開」などで検索するといくつか記事がヒットすると思い
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://dl.acm.org/doi/10.1145/3035918.3056101
オンプレからAws移行で変えた3つの意識
