広告技術部の toshimaru です。この記事はGunosy Advent Calendarの24日目の記事です。 qiita.com はじめに Gunosyではいくつかの管理画面においてRuby on Rails(以降Rails)を利用しています。具体的には下記の管理画面においてRailsが利用されています。 社内メンバー向け管理画面: 社内の担当者が記事の管理を行ったり、Gunosyアプリのユーザーの管理を行ったりできる管理画面です メディア様向け管理画面: Gunosyに記事を提供していただいているメディア様向け管理画面で、レポート閲覧や記事管理を行うことができます 広告主様向け管理画面: Gunosy Adsに広告を配信していただいている広告様向けの管理画面で、広告出稿やレポート閲覧を行うことができます 今日はそんなGunosy管理画面を支えているRails技術をいくつかピックア
こんにちは、サーバサイドエンジニアの @vkgtaro です。 1/23(火)にメルカリチャンネルの開発についてのイベントを開催したのでその開催後レポートをお届けします。 まずは開催当日は大雪の翌日で、足元が悪い中お越しいただいた方々には改めてお礼申し上げます。また、参加できなかった皆様におかれましてもお申し込みありがとうございました。 API エンジニアのイベントは今後も開催していきますので、次の機会によろしくお願いします。 mercari.connpass.com メルカリチャンネルはライブを通じたコミュニケーションで売れるフリマとして昨年7月にリリースされて以降、日々多くの機能開発、改善を行っています。 このイベントではそのメルカリチャンネルの成長を開発者視点で3名が登壇して伝えしました。 @bravewood による「メルカリチャンネルとは」 @vkgtaro による「急成長させる
はじめまして、2018年7月入社の sue445です。自称「フルスタックキュアエンジニア」です。最近はpixiv PAYのチームでRailsを書いたり社内gemを作ったりしています。 好きなプリキュアはキュアピースです。 前置き 先日Rails 5.2.1がリリースされました https://weblog.rubyonrails.org/2018/8/7/Rails-5-2-1-has-been-released/ pixiv PAYでもその対応を行っていて、先日本番環境にRails 5.2.1を投入しました 💪 ググると特定のバージョンでのアップデート方法はいろいろ見つかるのですが、どのバージョンでも使える汎用的な方法が意外になかったので紹介しようと思います。 Rails 4.1系以降はだいたいこの方法でアップデートしてきたのでそれなりに実績のある手法だと思います。 筆者スペック 初め
photo by pexels.com *1 この記事を書いたきっかけ niconegoto.hatenadiary.jp 「PinQulをクローズします」にて事業のふりかえりをしている文章の中に「アプリビジネスは完全にダウントレンドにある」という一節があって、ここから話題が広がっていったのを機に上記の記事を読みました。そして色々思うところがあったのです。 アプリビジネスは完全にダウントレンドというのは自分も前から思っていた。リッチな体験、通知を遅れることはアプリの利点だが、他PFからの流入なども含めたプロダクトのコアな検証はwebモバイルが1番早いはず。— sadakoa (@sadako_a_) August 16, 2018 (Twitter上で多くの共感を集めた投稿) 例えば「モバイルアプリがWebに負けはじめた理由」ではWebアプリがモバイルアプリに比べて優れているでろうという点
SREGの@takkyです。 この記事は All About Group(株式会社オールアバウト) Advent Calendar 2017 8日目の記事です。 (kubernetes ... k8s の8に合わせて8日の08:08に投稿してみました) 12/02に公開した記事ではGCPを1年間利用してどうだったかについてまとめました。 allabout-tech.hatenablog.com この記事ではGKE(Google Kubernetes Engine)を1年間利用して得られたノウハウについてまとめたいと思います。 前書き GCPの東京リージョンは2016/11/08にオープンされました。 cloudplatform-jp.googleblog.com その際にGoogle Container Engine(GKE) も東京リージョンで使えるようになりました。 社内ではまだDoc
prep-container-engine-for-prod.md https://cloud.google.com/solutions/prep-container-engine-for-prod プロジェクト・ネットワーク・クラスタの構成 プロジェクト GCP のすべてのリソースは プロジェクト の下に作成される プロジェクトごとに請求や IAM の管理が可能 本番やステージングといった複数環境のリソースを分離するためにもプロジェクトで分けよう ネットワークとサブネットワーク ネットワークはサブネットワーク・外部 IP アドレス・ファイアウォールルール・ルートなどをもつ GCP ではパフォーマンスやシンプルさを追求し、リージョンを跨げるネットワークになっている ファイアウォールはネットワークに対して設定できる ファイアウォールはデフォルトで GKE ノードへの流入トラフィックは禁止して
RailsアプリケーションをKubernetes(以後、k8s)で運用できるようにするための手順を書きます。 この記事はシリーズ連載記事の第三回です。 第一回 Docker編 第二回 Docker Compose/Dockerfile編 第三回 Kubernetes入門編 第四回 Kubernetes基礎編 第五回 Kubernetes応用編 第六回 Helm編 今回は下記について書きます。 最小限のk8s入門 minikubeの使い方 kubectlコマンドのチュートリアル 前提 macOSでの作業を前提としています。 使用したツールのバージョンなどは 初回 の記事を参照してください。 はじめにKubernetesには膨大な機能があるので、最初から汎用的な使い方を学ぼうとすると挫折しがちです。 このドキュメントでは、紹介する機能や概念を「初心者がRailsアプリを動かすために必要な機能」
こんにちは!プロジェクト推進室でエンジニアをしているTei1988です。 先日開催したSpeeeKaigi #3で「I ❤️ Kubernetes」を発表しました。 tech.speee.jp Kubernetesは、コンテナオーケストレーションツールです。 コンテナ化されたアプリケーションの管理やデプロイ、スケールなどを一手に引き受けます。 Google Container EngineからGoogle Kubernetes Engineに名称変更されたり、EKS(Amazon Elastic Container Service for Kubernetes)も始まったりと、スタンダードなツールになりつつあるので、Kubernetesを学んでおいても損にはならないかと思います。 DockerもKubernetesもほぼ初めてだったのですが、触っていくうちにいつのまにか❤️ になっていまし
また、これらに加えてコンテナの実行やイメージの管理を行うためのDockerや、分散型設定共有サービス「etcd」も必要となる。そのほか、異なるマシン上で稼動しているコンテナ間で通信を行うためにLinuxのブリッジ接続機能や「Flannel」、「OpenVSwitch」といった仮想ネットワーク機構なども利用される。 これらのうち、apiserverやcontroller-manager、scheduler、etcdについてはクラスタの管理を行うマスターサーバーで実行されるコンポーネントとなる。また、proxyやkubelet、dockerはコンテナを稼動させる各ノード(minionとも呼ばれる)上で実行されている必要がある。 マスターサーバーとノードを分けた一般的な構成は、次の図2のようになる。なお、kubectlについてはマスターサーバー上でも、別のクライアント上でも実行が可能だ。 図2
最近ではドキュメントも充実した感のあるKubernetesですが、実際の挙動ってどうなっているの?という部分に関しては ドキュメントを漁って読むに加えて、実際に手を動かして調べてみることでだいぶ理解が深まっていく感覚があります。 というわけで今回のテーマはKubernetesにおけるPodの名前解決はどのように動作しているのか、です。 公式ドキュメントのDNS for Services and Pods - Kubernetesを実際に手を動かしながら確認していきます。 Serviceリソースの名前解決 それでは早速シンプルな構成のk8s環境を用意して、その挙動を確認していきます。 Node: 1つ Master: 1つ 環境はGKEでも何でもいいのですが、今回はKOPSを使ってAWS上にk8s環境を用意することにしました。 Kopsでクラスタを構成すると以下の様にpodが作成されます。
こんにちは、@f_subal です。普段はおもに pixivFACTORY のフロントエンドを見ています。 今回は pixivFACTORY において、フロントエンドのビルドに Webpacker を利用するのをやめた話をします。 Webpacker をやめよう rails/webpacker は Ruby on Rails のプロジェクトに webpack を導入する際に用いられる gem です。必要な webpack の設定ファイルの生成や、Rails のテンプレートからビルド済みの JavaScript ファイルを読み出すために用いるヘルパー関数など、多数の機能を提供します。 結論から言うと、Webpacker を入れてもあまり良いことがありませんでした。単に必要が無いというより、あることによって面倒が増していると感じたので、剥がしました。以下 Webpacker が導入された Ra
まぁこれは基本的に膨大なログを見ている時に、ピンポイントで絞り込み検索をするという行動を前提としてるからだと思うんだけど、デバッグとかしてるときは「スゴク、コレジャナイ感…」がするわけです。 なので、そんな時はもう素直にkubectl get podsして、kubectl logs -f …. している自分がいました。 まぁこれでも充分なんです。充分なんですけど、辛い事が二つあって。 まず複数のコンテナにロードバランスされるペイロードに関しては自分が見てるコンテナにアクセスが来るとは限らないから全部のコンテナのログを見てるか、自分の見てるコンテナにアクセスが来るまで読み込み続けなければならない。 もうひとつは、開発をしている間の話なので、kubectl applyでdeploymentをガンガン入れ替えているのでコンテナもどんどん世代交代するわけです。そうすると… そう、当然コンテナはデコ
『メルカリ』 アプリの画面描画を高速化する技術、バックエンド・iOS・Androidの基本設計 多くのユーザーに愛されるフリマアプリ『メルカリ』ですが、そのスムーズな画面描画はどのような技術で生み出されているのでしょうか。同アプリの高速表示の秘密を、バックエンド、iOS、Androidの3方向からメルカリ社のエンジニア4人に聞きました。 バックエンドの高速化を支える技術 【Tips1】 画像のファイルサイズを最適化し、アプリ全体の通信量を抑える 【Tips2】データセンター間通信のレイテンシを抑える 【Tips3】アプリのありとあらゆる挙動を常にモニタリングする iOSアプリの高速化を支える技術 【Tips4】Objective-CからSwiftへの移行 & アーキテクチャの刷新 【Tips5】『UIStackView』を活用し、UIの描画をより滑らかにする Androidアプリの高速化を
こんにちは。 一休.comの開発基盤を担当しています、akasakas です。 今回は、画像最適化配信サービスであるimgixを宿泊・ レストランサイトに導入して、 画像最適化・サイトスピード改善につなげたお話をしたいと思います。 ここでお話しする内容 サイトスピードという観点での一休が抱えていた課題(の一部) imgixの特徴とそこでできる解決策 imgix導入の効果 imgix導入をする上で大変だったこと これから画像最適化を考える人たちへ まとめと感想 おまけ(与太話) 諸注意 imgixを導入して、画像最適化という面でサイトスピード改善につながりましたが、 サイトスピードという観点で一休が抱えている課題はまだまだあります。 imgixを導入すれば、サイトスピードは万事解決!!!という話ではありませんので、悪しからず。 サイトスピードという観点での一休が抱えていた課題(の一部) 画像
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く