シリコンバレーから失意の帰国をした十年選手のITエンジニア、生き残るため大学院で情報科学を学ぶ - Findy Engineer Lab
はじめまして、白山文彦（@fushiroyama）と申します。 インフラエンジニアとして5年、ソフトウェアエンジニアとして7年ほど働いて、現在は多国籍企業でクラウド関連の仕事に従事しています。 今年に入ってから、会社員としてフルタイムで勤務しながら、大学院の博士前期課程（修士課程）で情報科学を学んでいます。 この記事では、ITエンジニアとして10年以上もご飯を食べていながら、どうして今になって大学院生という道を選んだのか。業務で身についたものと、大学でしか学べないものとの違いは何なのか。そして最後に、それをどのように今後のキャリアにつなげていこうと考えているのか。そのあたりの葛藤や心の動きをシェアできたらなと考えています。 社会人大学院について 理系技術者は米国で圧倒的に尊敬されている 米国のエンジニアと日本のエンジニアの違い 学位と職業に強い関連がある米国 年齢に関係なく学位を目指すのが
株式会社ドワンゴを退職しました
ex-dwango.md 株式会社ドワンゴを退職しました 2011年3月15日に就職してから今日で8年と3ヶ月半・・・月にして99ヶ月・・・日数にして実に3033日 と・・・計算している間にも23秒が過ぎてしまったわけですが、株式会社ドワンゴを退職しました。 7月からはクックパッドで働きます。 ドワンゴでやってきたこと 2011年に入社して最初は今は亡きニコニコ静画(電子書籍)のバックエンドの開発をしました。 当時はphp縛りだったので仕方なくphp、こっそり gitを導入して会社の公式リポジトリであるsvnには定期的に git-svn でコピーする仕組みを作ったりしてました。 当時CIはちょっと導入されていたもののCDの概念は存在しなかったので、capistranoでphpをデプロイする仕組みを作ってそれも こっそり 運用していました。 浜町時代からドワンゴ社員御用達 BROZERS'
(インターネットやめろジェネレーターで作成) Ruby on Rails生みの親であり最強の逆張りおじさんであるところのDHHが昨年あたりからしきりに脱パプリッククラウドの主張をしている。 これは彼らの会社が運用しているBasecampやHEYのインフラをAWSから自社保有のベアメタルサーバーへ移行しようとしているからで、実際に移行作業は進んでおり、今後5年間で700万ドルのサーバー費用を節約できるだろうという見込みがあるようだ。 world.hey.com world.hey.com あとタイトルに「サーバーレスをやめろ」と書いたけどDHHのファンボである筆者の誇張表現であり、サーバーレスというキーワードに関しての言及は正確には以下のポストを読んで欲しい。 world.hey.com この文章における「the computing cycles」とは、一台のコンピュータが持つ計算能力全体を
こんにちは。はてなのアプリケーションエンジニアの id:onk です。 最近、若手エンジニアを中心に、いろいろな技術を見つめ直すワーキンググループをやっています。今回は、その中から「デプロイ」の会で発表されたことをまとめました（なお、私は会のとりまとめをやっている非若手です）。 デプロイのライフサイクルの違い Infrastructure Platformでのデプロイ Application Runtime Platformでのデプロイ Applicationsのデプロイ デプロイ方式はどのように変化してきたか In place から Blue/Green へ Immutable Infrastructure という考え方 オートスケールへの対応 push 型デプロイと pull 型デプロイ コンテナによるデプロイの現況 コントロールプレーンによって何が変わったか ECS におけるデプロイ
はじめに 何を書こうか迷ってたんですが、ちょうど副業始めて1年ほどたったので、どういうきっかけで始めたか、何をしてるのか、やってみたメリットなどを書いていこうと思います。 なぜ副業×AWSなのかというと、自分が副業をやっていく中で普段AWSに触れていることが強みになっていたので、単に副業だけじゃなくAWSも混ぜてみました。 これから副業を始めようと思っている人、特に本業で役割が変わってあまりコード書けなくなった人に参考になれば。 自己紹介 本業ではSREという部署でCloud Architecture Grpというチームを持っており、自社サービスであるCOMPANYのクラウドネイティブ化を推進しています。 主にクラウドプラットフォームとしてはAWSを利用しているため、日常的にAWSのサービスに触れる機会が多いです。 そんな本業の傍ら、3社で副業やってます。(20名規模ぐらいのベンチャー)
コンテナフレンドリーではなかったRailsアプリケーションをDocker(ECS)に移行するまでの戦い - クラウドワークス エンジニアブログ
はじめに SREチームの @minamijoyo です。 先日 CrowdWorks (crowdworks.jp) の本番環境のRailsアプリケーションを Docker (AWS ECS: Elastic Container Service) に移行しました。 CrowdWorksは2012年にサービスを開始し、2019年10月現在、ユーザ数は300万人、月間で数億円規模のお仕事がやりとりされる、国内最大級のクラウドソーシングプラットフォームにまで成長しました。 サービスの規模拡大に合わせて、ソースコードも数十万行規模に成長し、 決して小さくはない規模のRailsアプリケーションに成長しました。 CrowdWorksの開発環境にDockerが導入されたのはもうかれこれ3年半前の2016年の4月頃、2017年1月頃にはCrowdWorks本体から切り出された一部の機能で本番環境に投入され
SREチーム 鈴木心之介 です。 職歴の空白 を経て参画しました。 社名変更して co.jp ドメインを複数保有する技術 の節は皆様ありがとうございました。 たぶんそのうち書かれるだろう「Dockerコンテナ移行しました」記事の先史時代の記録として、また、事業の成長に併走してきたEC2でのアーキテクチャの御焚上として奏上するものです。 問題意識 アプリケーションはRuby on Railsで実装し、インフラはAWSにEC2, RDS, S3を中核に構成してます。運用状況はEC2に限らず大変きびしく、早くどうにかしないと事業の成長の足枷になりそうでした。入社前のカジュアル面談で伺っていた情報と、入社後の情報収集から、大枠の問題意識を以下4つに絞りました。 デプロイメント セキュリティ スケーラビリティ ディザスタリカバリ どれも解決すべきで、優先順位にみなさま一家言あるかと思います。ただセキ
DNS における Master/Slave vs Primary/Secondary の現状（2020/06） - suu-g's diary
BLM の関係でコンピュータ業界の Master / Slave という言葉遣いにもメスが入ろうとしているいま、 DNS ではどうなっているんだっけ、というのがふと気になった。 というのも mattn さんの blacklist/whitelist master/slave に関する情報集め を見たから。あとコメントもしたから。 で、調べて行ったところ、ひとことで言えば既に Primary / Secondary になってるんだけど、そもそもこの用語自体そんな使わないよな、と思ったのだけど、そのあたりを解説するのは元記事の関心ごとと全く違うってことで、改めて自分のブログの記事にしてみたというわけ。 DNS は趣味でしかないので、ツッコミ大歓迎です。 Primary/Secondary が正しい用語です 用語に困ったら RFC 8499 (Jan, 2019) が正しい参照先。こう書いてある
Railsでpumaやsidekiqのスレッド数とコネクションプールの数ってどうやって決めるんですか | 働くひとと組織の健康を創る iCARE
この記事はiCARE Dev Advent Calendar 2022 第1レーン24日目の記事です。 Railsの基本原則の一つに「メニューはおまかせ」があり、デフォルトで設定を良い感じにしてくれています。しかし、本当に自分のユースケースでも問題ない設定だと自信を持って言うためには、なぜこの設定になっているのかの背景知識が必要になります。例えばrails newをするとpumaのスレッド数はデフォルト5、データベースのコネクションプール数も5になっています。これは自分のユースケースで適切な値なのでしょうか？どういうときにいくつに設定するのが正しいのでしょうか？ pumaのスレッド数をどうやって決めるのか pumaはRailsのデフォルトのアプリケーションサーバであり、複数プロセス、複数スレッドで動くアプリケーションサーバです。この記事を執筆している時点で最も利用率の高いアプリケーションサ
GMO ペパボを退職した, 送別会を渋谷のなるとキッチンで開催してもらった - HsbtDiary(2022-10-31)
■ GMO ペパボを退職した 10年と5ヶ月勤務した GMO ペパボの最終出社日(=退職日)でした。GMO ペパボでは執行役員としてエンジニアリングのトップマネジメントを担当していました。 せっかくなので、10年前にエンジニアとして入社してプロダクト開発を始めた時から今までにやってきたことを振り返ります。 ふつうの開発を根付かせた 「ふつう」とは何かという話はありますが、おおよそ同じくらいの規模の会社が当たり前のように行なっているプラクティスや技術を当たり前のように使えるようになる、というくらいの意味合いです。10年前の2012年にGMOペパボ(当時はpaperboy&co)に入社した時は、production のサーバーにログインしてコードを変更して、動いたらそこから svn に commit をする、というバックアップなのか...?という開発が行われてました。 当時一緒に入社した @k
はてなブログをECSに移行してリリース頻度も改善した話 - Hatena Developer Blog
この記事ははてなエンジニア Advent Calendar 2022の26日目のエントリです。 こんにちは id:cohalz です。はてなブログでは2022年7月にインフラをAmazon EC2からAWS ECS(AWS Fargate)に移行するプロジェクトが完了しました。 プロジェクトは2021年9月から始まったので約10ヶ月間という大きなプロジェクトでした。 プロジェクト完了までに行ってきたことのうち、特に面白かったところなどをこの記事で実施した順に振り返ってみます。 はてなブログのインフラのこれまで アプリケーションを動かせるようにする ALBを追加する 検証環境を用意だけしておく プロキシの設定埋め込み 証明書の配信 アクセスログを配送できるようにする アクセスログの形式を新しくする EC2でもFirehoseを経由するように タイムゾーンをUTCに統一 FirehoseのLa
現在 estie では、デプロイの改善・統一に取り組んでいます。複数プロダクトのそれぞれの技術スタックが大きく違う中、どう考えたら効率的なデプロイを組めるのか。2024年のデプロイの原則について、あらためて考えてみました。
ニコニ立体を直した話 - Qiita
ステージング化 本番のVMについてはここでAMIを取って完了としましたが、ステージングは設定を変更しなければなりませんでした。本番へのアクセスが起こらないよう設定の洗い出しを行い、地道に一つ一つ変更していき、ステージングとして動作するように調整を行いました。地味な作業でしたが、システム間のつながりを把握するという点でとても効率的だったので思ったほど無意味な作業ではありませんでした。 データ移行（BLOB to S3) データ移行はリプレイスプロジェクトでも難易度が高い部分でした。 ニコニ立体は3Dモデルホスティングサービスですが、この3Dモデルのファイル容量が大きく、移行に非常に時間がかかりました。試算では移行に２４時間かかると出たため、日々増えるデータをどのようにスムーズに移行するかについて悩みました。 立体の負債解消を手伝ってくれていたまさらっき氏が偶然ALBのRuby on Lamb
新人研修の内容を検討しているのですが、それにあたり各社の新人研修を調査しました。 なお本記事は、@gcchaan氏のGitHub Gistにある「研修資料まとめ」を参考に作成しております。 @gcchaan氏の「研修資料まとめ」はとても素晴らしいまとめで、これを見ると各社がどのように新人エンジニアを育成しているのか見てとれたり、新人エンジニアがどのような研修を経て成長していくのか垣間見えます。 DMM.com（2019） DMM.comの研修で紹介されている技術書 GMOペパボ（2019） LINE（2018） Spee（2016） Wantedly（2019） ウエディングパーク（2019） エムスリー（2018） 研修概要 KAYAC（2017） クックパッド（2016） GREE（2014） ぐるなび（2017） LEMPについて サイバーエージェント（2019） エンジニア研修がど
こんにちは、sue445です。 先日社内で使ってるGitLabのリプレイスをしたのでその辺の話をしたいと思います。 リプレイスの内容 今回のGitLabリプレイスでは主に下記を行いました。 サーバ移設に伴いURL以外全部変えた レガシーな環境で運用されていたGitLabを全てDockerコンテナに載せた MySQLからPostgreSQLに移行 以上を1時間弱のメンテでやりきった 構成 ざっくり書くと、SSL終端のフロントサーバのみ同じで、それ以外のバックエンドを全部変えました。 旧 APサーバ Debian Wheezy CPU: Intel Xeon E5-2640v2 * 2 Memory: 40GB Disk: 64G + 512G MySQL兼Redisサーバ Debian Wheezy CPU: Intel Xeon X3430 Memory: 8GB Disk: 256G M
Web開発の歴史の復習の仕方 悲報: WEB+DB PRESSが休刊 22年以上続いていたWEB+DB PRESSが休刊するそうです。Software Design、WEB+DB PRESS共に年間購読していたのですが、とても残念です。 日本語と英語、少し中国語の技術書を普段から読み漁っているのですが、本ほどガッツリでなく、ブログよりはちゃんとバリデートされた上でトレンドをおさえた雑誌文化は割合日本的で、他の言語圏だとあまりない文化だとも感じています。 技術評論社からでているSoftware Design、WEB+DB PRESSなのですが、Software Designの創刊が1990年11月で、WEB+DB PRESS Vol.1が2000年12月で10年の差があります。 どちらかというとSoftware Designがインフラ&バックエンドでWEB+DB PRESSがバックエンド&ク
CTO室SREの侘美です。好きなLinuxディストリビューションはLinux Mintです。 メドピアでは現在多数のサービスを運用しており、そのほとんどがAmazon ECSを構成の中核として利用しています。 ECSに対してデプロイを行う方法としては、CodeDeploy、CodePipeline、Copilot（ecs-cli）等があり、CloudFormationやTerraform等のIaCツールで何をどこまで管理するかも合わせて検討する必要があります。 どの方法にもメリット・デメリットがあり、Twitterや技術ブログを観測している範囲ではデファクトスタンダードと呼べる方法は未だに無いように思われます。 メドピアで最初にECSを利用し始めたのは2018年ころであり、これまで試行錯誤しながらECSのデプロイ方法とタスク定義の管理方法を模索してきました。 今回はメドピア社内で試してきた
Slack ワークフロー × GitHub Actions で何時でも誰でも楽なステージングデプロイを実現する - Pepabo Tech Portal
こんにちは！ 先日最終話が放映された Dr.STONE 2 期が始まった頃、先が気になりすぎて漫画版を大人買いした CTO室 鹿児島オフィスチームのよしこ @yoshikouki です。これぞ社会人の嗜みだなと感慨深くなった30歳の春。 今回は私が運用・開発に携わっているホスティング事業部で Slack ワークフローと GitHub Actions を組み合わせて業務を改善しましたので紹介したいと思います。本改善は、サービスの本番環境に近いステージング環境へのデプロイ作業を Slack 上で行えるようにして、デプロイのための環境構築を不要にしたことに加えて必要なステップを 1 つだけにすることができました。 これまでステージングデプロイの問題点 環境構築についての比較 改善前 改善後 デプロイフローについての比較 改善前 改善後 どのようにして改善したのか 実際の操作画面と流れ 実装方法
3行まとめ MRSKは「コンテナ時代のCapistrano（Capistrano for Containers）」的なデプロイツール。すごくDHHぽい。 $5くらいの素のcompute instanceがHerokuみたいに使えるようになる(ただしDBやS3やRedisは必要に応じて別途用意する前提、合わせて別インスタンスで立ち上げる機能もあり) 37Signalsではproductionで使ってるようだけどまだまだ荒削りなので、しばらくは一緒に開発したいくらいの勢いで使いたい人向け MRSKとは MRSKはRailsの創始者DHHが新しく作ったデプロイツールです。 初コミットは2023年の1月7日ということで真新しいプロダクトなのですが、中身を見るとあまり新しそうに見えないというか、今どきのクラウドネイティブな世界観から見ると正直懐かしい感じもあります。なんで今これが作られたのでしょうか
スマホゲーム業界におけるPHPの歴史とLaravel Octaneで広がるこれからのPHP | CyberAgent Developers Blog
3月24日、サイバーエージェントのエンジニア・クリエイターによる技術カンファレンス「CyberAgent Developer Conference2022」を開催しました。本記事では、「スマホゲーム業界におけるPHPの歴史とLaravel Octaneで広がるこれからのPHP」の様子をお届けします。 目次 ■サイバーエージェントグループのゲーム事業の歴史とPHP ■PHPで培ったもの ■多様化するゲームの要件とサイバーエージェントグループでの事例 ■PHPの変革「Swoole」「Laravel Octane」の登場 ■Laravel Octane Deep Dive ■まとめ ■サイバーエージェントグループのゲーム事業の歴史とPHP まずはサイバーエージェントグループのゲーム事業の歴史とPHPについて振り返ります。サイバーエージェントグループでは2009年からゲーム事業に参入しており、20
よりよい開発体験を求めて─ OSSと本業であるインフラエンジニアの二軸を生かし、自らの力で組織の開発力を向上させる - Findy Engineer Lab
ファッション通販サイト「ZOZOTOWN」の開発・運用を担うZOZOテクノロジーズでは、2004年の設立から使われ続けてきたモノリスなアプリケーションをマイクロサービス化するとともに、オンプレミスからマルチクラウドへと大きなシステムのリプレースを進めています。 その中心でMLOpsやSREといった基盤の構築を担う瀬尾直利（@sonots、そのっつ）さんは、インフラエンジニアとして事業にコミットしているだけでなく、CRubyやFluentd、Chainerといったさまざまなオープンソースソフトウェア（OSS）のコミッターという顔も持っています。 一貫して「開発体験の良さ」を追い求めてきた瀬尾さんの中で、プロジェクトの課題を解決する業務と、OSSコミュニティにおけるプライベートの活動はどのようにシンクロしているのでしょうか。キャリアの軌跡を振り返りながら、2つの軸を生かしたソフトウェアエンジニ
おしらせ 2021/06/27 の Drecom SRE Sunday にて、 この記事にかかれている EKS 移行に関する情報共有を行います、ぜひご参加ください！ Drecom SRE Sunday (connpass) はじめに こんにちは！ enza SREチームのmendと申します！ 先日の安藤さんの記事「古き良きRailsアプリケーションをコンテナ化してKubernetes上で動かす」にもある通り、運用しているプロダクトをAmazon EC2からAmazon EKSに移行しました。 プロダクトをダウンタイムなしにEC2からEKSに移行しましたので、今回はダウンタイムなしを実現したインフラ側の構成について紹介させて頂きたいと思います。 背景 まず背景としましては、私の関わっているプロダクトはこれまでEC2で動作しておりました。 EC2上でdockerコンテナを起動しているのではなく
この記事はクラウドワークス アドベントカレンダー6日目の記事です。 前日の記事は@bugfireのgithub-script は便利でした。GitHub Actionsでのちょっとした作業が捗りますね！ SREチームの@kangaechuです。 気がつくと入社から2年が経ちました。2年前のAdvent Calendarでは ぴよぴよSREという記事を書くくらい何もわかっていませんでしたが、ようやく自分なりに動けるようになってきました。 この記事ではcrowdworks.jpのSREチームで、この2年間でどのようなことをやっていたのかを振り返ります。 SREチームの範囲は幅広く、いろいろなことをやっていました。今回はDocker化とTerraformの2つの取り組みについてご紹介します。 なんで1年じゃなく2年かって？去年はaws-vault についてのあれこれを書いたからだよ。 Docke
Rails × ECS 運用してみたわかった起動タイプ EC2, Fargate の使い所 - メドピア開発者ブログ
メドピアマッスル部上腕二頭筋担当、CTO室 kenzo0107 です。 今回はメドピアの直近のプロジェクトで採用している Rails × ECS Fargate についてです。 直近プロジェクト 直近プロジェクトでは AWS ECS を採用しています。 2018年10月にリリースした スギサポ deli は、メドピアで Fargate 初採用となったプロジェクトです。 スギサポ deli とは？ sugisapo.ws 病気で食事制限が必要な方やシニアの方々、より健康な食生活を目指す方など、誰もが美味しく召し上がれるお食事をお届けするサービスです。 「食事制限」 と聞くと、簡素な食事をイメージされる方もいらっしゃると思いますが 一度見て頂くとお分かりの通り、かなりバラエティに富んだ内容となっており、目にも美味しい品々が並んでおります。 是非一度お試しいただければ幸いです♪ 今回お話ししたい
CTO 室 SRE kenzo0107 です。 以前執筆した ECS を利用した検証環境の自動構築について、運用開始から3年の時を経ました。 実運用とその上で頂いた要望を取り入れ変化してきましたので、その経緯を綴ります。 tech.medpeer.co.jp 本稿、議論を重ね改善を進めて頂いたチームメンバーの知見を集めた元気玉ブログとなっております。 前提 社内では、以下の様に呼び分けしています。 本番相当の検証環境を STG 環境 本記事で説明する自動構築される仕組みを持つ環境を QA 環境*1 検証環境の自動構築の目的 開発した機能を開発担当者以外でも簡易的に確認できる様にし、以下を促進します。 ディレクターと開発者の仕様齟齬を減らす 改善のサイクルを高速化する 当時の検証環境の自動構築の仕組み 大まかな流れ ① ブランチ qa/foo を push ② CircleCI 実行 ③ C
ここ数年、色んな人に「パーフェクト Ruby on Railsの改訂版まだですか」と言われて申し訳ない気持ちでいっぱいでした。が、ついに改訂版が発売されることになりました！もちろん最新のRailsである6.0に対応しています。 発売日は7月25日ですが、先行して発売している書店もあるそうです。 パーフェクトRuby on Rails 【増補改訂版】：書籍案内｜技術評論社 ブログで振り返ると、第1版を書いたのは6年前だったようです。6年前といえばRailsは4.1がリリースされた頃で、フロントエンドはCoffeeScriptを書いてSprocketsでコンパイル、デプロイはCapistranoを使うのが主流だったような気がします。6年でだいぶRailsによる開発の進め方が変わりましたね。このあたりはもちろん第2版で更新されて、WebpackerやDockerに置き換わっています。 改訂2版の
CloudFormation 一撃で EC2 の Blue/Green Deployment の CodePipeline を構築する | DevelopersIO
準備 CodeCommitに以下をプッシュします。 なお、CodePipelineによる自動デプロイではファイル上書きデプロイを設定できないので、必要に応じて appspec.ymlで元のファイルを削除するように対応します。 ソースコード(index.html, hello.conf) appspec.yml (本稿では beforeInstall.sh を利用) ちなみに、index.html や hello.conf の素材は こちら を使っています。 参考 ## appspec.yml version: 0.0 os: linux files: - source: ./hello.conf destination: /etc/nginx/conf.d/ - source: ./index.html destination: /usr/share/nginx/html/ hooks:
グループ会社のインフラをECS/Fargateに移行して振り返る | ランサーズ（Lancers）エンジニアブログ
皆さん元気ですか！？SREチームの@adachin0817です。去年から行っていた移行プロジェクトで、グループ会社である、シクロマーケティング株式会社の「ミギウデ」をさくらVPSからAWSへ移行しました。今回、移行背景やECS/Fargateでのコンテナ運用について簡単にご紹介と振り返りを行ってみたいと思います。 なぜAWSへ移行するのか AWSへ移行すると冗長性の担保などが挙げられますが、一番は開発環境やインフラなど、すべてランサーズに統一させるということが第一の目的です。それに伴い、ミギウデ自体のサービスがシンプルなインフラ構成ということもあり、インフラ運用の手間をなくしたいということから、ECS/Fargateで初の外部サービスとしてコンテナ運用にチャレンジしてみようとなりました。 目的とコンテナ化にするメリット ・内部統制対応 ・S3、RDSを利用したバックアップ ・CloudWa
こんにちは、エムスリーエンジニアリンググループのコンシューマチームに所属している園田(@ryoryoryohei)です。今回は 15 年以上続いている弊社の C 向けサービスである AskDoctors の AWS 移行で苦労した点や工夫した点などをお伝えしたいと思います。 はじめに 移行フェーズ 苦労したポイント デプロイ方法の変更 バッチのアーキテクチャ 泥臭い修正 待ち時間 定型外のリリースフロー AWS 移行後のこと End-to-End のレイテンシー悪化 バッチ起動エラー Redis メモリ逼迫 オンプレの API に対する Connection Failed おわりに We are hiring! はじめに 弊社では to C のサービスとして AskDoctors という医師に直接相談できる Rails のサービスを 15 年以上前から運営しています。 www.askdoc
なぜフィヨルドブートキャンプに入ったのか？ サイトデザインが「なんとなくいいな〜」と思った 現場力がつきそうだと思った お金で釣っていなかった 決めたきっかけ 何を学んだのか？ どれだけやったか？ どんなことに苦労したか？ lsコマンド作成 デプロイ課題 子育てとの両立はエグい 卒業するために何をしたか？ 根性、執念、負けず嫌い ブログでアウトプット 技術を楽しむ 楽しさの閾値を超えるまで我慢が必要かも 卒業して思うこと、身についたこと プログラミング楽しい 課題を解決するための考え方 まだまだわからないことだらけ どんなエンジニアになりたいか 終わりに 追記：卒業Tシャツと修了証明書をゲット！ 追記2：フィヨルドブートキャンプが「フクオカRuby大賞」を受賞 追記3：卒業後、どうなった？ フィヨルドブートキャンプ、ぶっちゃけどうなの？ 追記 2021/12/21 メリット デメリット 2
Kafkaに接続するJavaアプリケーションをGravitonインスタンスへ移行してパフォーマンスを改善する - joker1007’s diary
社内向けのドキュメントと兼用したので、前提とかメンバー向けの解説が含まれているので、前後のパフォーマンスの変化だけを見たい人は、下の方のグラフ画像までスクロールしてください。 gravitonインスタンスを活用するモチベーション ワークロードによる相性はあるが、特にマルチスレッド性能で既存のインスタンスより性能向上が見られる上にコストが安いため、うまくフィットすれば性能改善とコスト削減の双方でメリットがある。 また、周辺ハードウェアもアップデートされているため、エフェメラルストレージ付きのインスタンスのストレージサイズが増えているなどのメリットもある。 特に現時点ではr6gdインスタンスが利用したかった。 gravitonインスタンスを利用するためarm64アーキテクチャへの対応 gravitonインスタンスはarm64 (aarch64) アーキテクチャのCPUのため、既存のx86_64
STORES Rails アプリを Zeitwerk 有効化するまでの道のり - STORES Product Blog
こんにちは、ヘイ株式会社でエンジニアをしている id:hogelog です。 2021年6月に入社し CTO 室という部署に所属しつつなんだかあちこちの部署に首を突っ込むような役割をしています。まだ入社したばかりで把握してないものも多いですが、ビジネスの勢い、人の活気、やらなきゃいけないことばかりという雰囲気をとても楽しんでいます。 さてここは技術ブログ。なので技術の話をします。今回は STORES https://stores.jp/ec を支えるなかなか大きなモノリシック Rails アプリケーションのオートローダーを Zeitwerk へと切り替えた業務について紹介します。最新技術でもなく、Rails の設定項目の一つ Rails.application.config.autoloader の値を :classic から :zeitwerk に切り替えるというだけの地味な内容ですが、
TL;DR 3行で。 シンプルで セキュアな Ruby on Rails on ECS by Terraform を作りました。 目次 はじめに 本構成のテーマ リポジトリ アーキテクチャ Terraform側のTips Rails側のTips さらなるカスタマイズ はじめに ここ数年、業務やプライベートで様々なパターンのRuby on Rails + AWS ECS構成を構築してきました。 例えば、構築したことがるパターンを要素ごとに列挙するとざっと以下のようになります。 フロント部分 ALBのみ CloudFront -> ALB assetsのみCloudFront ECS 起動タイプEC2 起動タイプFargate 2種の混在 デプロイパイプライン 全部GitHub Actions Capistrano + ecs-cli CodePipeline + CodeBuild Code
GitHub - YoshiiRyo1/getting-start-ecs-blue-green-deploy
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
こんにちは。 delyコマース事業部エンジニアのjohnです。 もともとは開発部でiOSエンジニアとしてクラシルのiOSアプリ開発をやっていましたが、今年のはじめから新規事業のコマース事業部でwebのフロントエンドやRailsアプリケーションとかいろいろと開発をしています。 この記事は「dely Advent Calendar 2019」の16日目の記事です。 昨日はSREの井上さんによる「10分で完成！WEBサイトパフォーマンス計測基盤 ver.2019」という記事でした。 tech.dely.jp 今回は、Capistranoを使ってRailsアプリケーションをデプロイしたときに環境変数でハマった話を書きます。 なかなか、これ系の記事が少なかったので、gemの中を見るところまでしてみました。 1つのサーバーを使いまわしてのデプロイの話です。インフラがコード化(Infrastructur
週刊Railsウォッチ（20200427前編）Railsで避けたい8つのミス、ridgepole導入の注意点、RDS ProxyのPostgreSQL対応ほか｜TechRacho by BPS株式会社
2020.04.27 週刊Railsウォッチ（20200427前編）Railsで避けたい8つのミス、ridgepole導入の注意点、RDS ProxyのPostgreSQL対応ほか こんにちは、hachi8833です。 つっつきボイス:「近所のビアパブに注文しておいたビール取りに行ってた🍺」「お疲れさまです！」「最近酒類の販売免許が飲食店向けに割と簡単な手続きで申請できるようになったじゃないですか」「あ、酒の持ち帰りは居酒屋の免許とは別なのか😳」「持ち帰りだと販売として扱われるので☺️」「なるほど〜」「本来だと酒販免許を取るのはかなり面倒なんですけど、その店は5日ぐらいで取れたって😋」「そういえば都内で店やってる知り合いも2日で取れたって言ってました😋」「都内だと特に早いらしい」「ではつっつき始めましょう〜」 参考: 酒類のテイクアウト販売が可能になる「期限付酒類小売業免許」とは？
Deploy web apps anywhere
Kamal offers zero-downtime deploys, rolling restarts, asset bridging, remote builds, accessory service management, and everything else you need to deploy and manage your web app in production with Docker. Originally built for Rails apps, Kamal will work with any type of web app that can be containerized. Read the docs View the source Vision In the past decade+, there’s been an explosion in commerc
はじめに おはもに～。id:utgwkk です。最近の京都は夏のような日もあって、計算機にはつらい季節になりつつありますね。 今日は、部員向けWebサービスを部内Kubernetes (以下、k8s) クラスタに移設した話をします。 部内k8sクラスタについて KMCでは、サークルの部内サーバーでk8sクラスタを運用しています。KMCの部員であれば誰でも自由にアプリケーションをk8sクラスタ上で稼動させることができます。k8sクラスタを構築した経緯や技術的な詳細については、以下の記事をごらんください。 blog.kmc.gr.jp 移設したWebサービスについて 今回移設したWebサービスは、部員向けのイラスト投稿サービス (通称 God Illust Uploader、以下では神ロダと呼びます) です。KMCでは毎年お絵描きプロジェクトという勉強会・練習会を開催しており、課題を提出する場
こんにちは、食べログシステム本部長の京和です。 今年の4月から本部長になりました。さらに4月に娘が生まれました 本エントリでは食べログで1年を通じて取り組んだ、大規模なレガシーシステムの段階的な改善について紹介します。[翻訳] Shopifyにおけるモジュラモノリスへの移行 に続いて2記事目のアドベントカレンダーになります。 どのように段階的に進めるか 食べログは今年で15年目のサービスで、Railsになってからは13年が経過しています。これだけ歴史があればあちこちにガタが来ているのは当然で、無数にある課題に対してどこからどのように取り組んでいくかを最初に決める必要がありました。 まず最初の前提として以下のように考えました。 既存のビジネスや開発を止めるような悪影響を与えない。むしろなるべく早くポジティブな影響を与えていきたい。 これだけ歴史のあるシステムを改善していくのは長い時間がかかる
はじめに STORES 予約でSREを担当している矢作です。 STORES 予約では今年(2022年)の9月にアプリケーションを構成する大多数のサーバーをEC2からECSへと移行することでコンテナ化(以降ECS化)しました。 今回はコンテナ化をすることで解決を目指した課題についてや、コンテナ環境でどういったアーキテクチャを構築し、その後移行していったのかについてお話ししていきます。 コンテナ化以前の構成 コンテナ化する前のSTORES 予約のざっくりとしたインフラ構成は以下のようになっています。 一台のEC2インスタンスの中に、Nginx(緑のアイコン)、Next.js(黒のアイコン)を利用して作られたコードベース、Railsを利用して作られたコードベースの3者が同梱されています。 Nginxがリクエストを受け取り、パスベースでNext.jsかRailsのプロセスへとインスタンス内でリバー
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
最近のDHH「サーバーレスをやめろ」 - laiso
デプロイ今昔 - Hatena Developer Blog
副業×AWSでわりと人生変わったエンジニアの話 - Qiita
猛烈に成長するSaaSのインフラを猛烈にカイゼンする技術 - ANDPAD Tech Blog
デプロイ再考2024/reconsidering-deploy-in-2024
各社のエンジニア研修で探る、新人エンジニアに必要な技術と駆け出しエンジニアの成長論 - このすみノート
GitLab令和最初のリプレイス。フルコンテナ化ポスグレ移行 - pixiv inside
Software Design、WEB+DB PRESS全巻読破のすすめ
メドピアのECSデプロイ方法の変遷 - メドピア開発者ブログ
コンテナ向けデプロイツールMRSKを試してみる - Qiita
ダウンタイムなしでEC2からEKSへ移行しました！ - Tech Inside Drecom
SREチームに入ってからの2年間にチームでやってきたこと - クラウドワークス エンジニアブログ
ECS を利用した検証環境の自動構築 ~運用3年を経て得た知見~ - メドピア開発者ブログ
パーフェクト Ruby on Railsの改訂2版を書きました - おもしろwebサービス開発日記
15年間続いているサービスをクラウドに移行しています (part 2) - エムスリーテックブログ
フィヨルドブートキャンプを卒業しました。 - Just do IT
シンプルでセキュアなRails on ECSのTerraformによる実装 - Qiita
Rails初心者がハマったCapistranoの環境変数 - dely Tech Blog
部内Kubernetesクラスタに部員向けWebサービスを移設しました - KMC活動ブログ
食べログの大規模なレガシーシステムを段階的に改善していく取り組み - Qiita
STORES 予約 コンテナ化への道のり 前編 - STORES Product Blog