2024年1月末まで在籍していますが昨年12月に業務は終えていて、いまは有休消化期間中です。2010年から約14年間勤めてきた、自分の生き様そのものとも言えるクックパッドを離れるのには、表現しきれないほど大きく、複雑な思いがあります。 僕がこの14年間でやってきたことを振り返ってみます。 入社 クックパッドに入社した時は新卒3年目相当で、26歳でした。もともと料理と Ruby が好きで、当時まだ珍しかった Ruby on Rails でサービス開発をしているらしいという点や、当時からネットウォッチしていた @ryo_katsuma さんが所属していること、直属の上司の井原さんが転職したことが決め手になり、体当たりで飛び込みました。当時の僕はほとんど実績もなく、入れてもらえるかギリギリのところだったと思いますが、おそらく井原さんが頑張って交渉してくれたのだと思います。本当に感謝しています。こ
はじめに ITの世界で「低レイヤ技術」と呼ばれるものがあります。明確に定義されているわけではありませんが、アプリケーションのような直接エンドユーザに触れる部分ではなく、しかもなるべく生のコンピュータに近い部分、たとえばOSカーネルやコンパイラ、CPUを開発する技術などがあります。これらの技術に明るい人はそうそういないのですが、「やってみたい」という根強い人気があります。 学生のかたでもセキュリティキャンプなどで実際にある程度身につけてしまうような人もいます。そしてますますこの手の技術に趣味としてのめり込んでいって楽しくなる…というところまではいいのですが、「ではこの技術を会得した先に何があるのか」と不安になる人も多いようです。とくに学生さんの場合は「低レイヤ技術を使って今後なんらかの仕事をして生きていけるのか？」といったことが気になるようです。今日もそのような話を少し耳にしたので、自分の経
技術部 SRE グループの mozamimy です。 クックパッドでは、 SRE が中心となって、サービスを動かす基盤の大部分である AWS のコスト最適化を組織的に取り組んでいます。 昨年夏に公開した記事である、インフラのコスト最適化の重要性と RI (リザーブドインスタンス) の維持管理におけるクックパッドでの取り組みでは、 なぜインフラのコスト最適化が必要なのか、具体的にどのような考え方に沿って進めてゆけばよいのか。 SRE が一括して管理する AWS のリソースプールそのもののコスト最適化を実践するための具体的な取り組みの一例として、RI のモニタリングや異常時の対応フローによる維持管理。 といった話題にフォーカスしました。 今回は、インフラにかかるコストを正しく「説明」するための取り組みということで、コスト最適化に貢献する社内アプリケーションである Costco (Cost Co
AWS、超高性能なクラウド基盤を実現するために独自開発した技術を説明。AWS re:Invent 2019 Amazon Web Services（AWS）のデベロッパー向け年次イベント「AWS re:Invent 2019」が、米ラスベガスで開催中です。 基調講演の前夜に行われたセッション「Monday Night Live」には、AWSグローバルインフラストラクチャ＆カスタマサポート担当VP、Peter DeSantis氏が登壇。 そのためにどのような技術がAWSのインフラで使われているのかを説明しました。 独自のスイッチやNitro Controllerで高性能ネットワークを実現 超高速な処理をクラウド上で実現する上でカギとなる技術の1つ目は、広帯域で低レイテンシなネットワークの実現です。 AWSはそのためにネットワークスイッチ機器と、それらを制御するためのソフトウェアを独自に開発。
IT業界のヒエラルキー 20年もの間、いわゆるSIer業界を見ているとこの、IT業界に根付くヒエラルキーの存在はいくら弊害が叫ばれても変わる気配がありません。それを見事に見える化した記事がありますのでご紹介します。 blog.ryo-okui-assign.com 今回は、SIerからのキャリアアップや転職先について詳しく解説をしていきたいと思います。 ビジネスとデジタルが融合し一体化している昨今では、SIer出身の人材、SEは転職市場でも非常に需要が高まっています。しかし、不用意な転職は、結局やることが変わらなかったり、やりたいことに注力できない環境だったりとリスクをはらんでいます。 そのため、正しくSE・SIerの転職市場を把握をしたうえで、転職活動を進める必要があります。 一般に出回っていない情報も沢山お伝えするので、是非参考にしてください。 SIerと区切ってはいますが、ユーザーサ
技術部 SRE グループの mozamimy です。 クックパッドでは、 SRE が中心となって、サービスを動かす基盤の大部分である AWS のコスト最適化を組織的に取り組んでいるため、今回はそれについてご紹介します。 前半では、そもそもの話として「なぜコスト最適化が重要なのか」「何が難しいのか」「何をすべきなのか」といったことを述べます。これは、当たり前すぎて逆に陽に語られることが少ない (とわたしは感じています) トピックで、一度しっかり言語化しておいてもいいかなと考えたからです。内容のほとんどはわたしの脳内ダンプで、クックパッドという会社のコンテキストや組織としてのステージが前提になっているため、大多数の組織について当てはまる内容とは限りません。 後半では、コスト最適化の一例として、リザーブドインスタンス (以下 RI と略記) を維持管理するためのフローと、それを支えるモニタリング
本連載では、比較的「小規模」な「受託」開発を実施する際のAWS活用の勘所を、実際の開発現場での経験を元に紹介します。大規模な開発では当てはまらない部分もあると思いますが、可能な限りインフラ関連の工数を少なくし、効率的に開発を実施するために、最低限抑えておく実務上役立つ点について、解説します。本記事では、小規模なフルスクラッチの業務システムをビジネスとし、開発を実施する際に参考となるAWSのアーキテクチャや工数のかかる工程、留意すべきセキュリティに関するポイントを紹介します。 はじめに 比較的小規模なフルスクラッチのシステム開発（1〜20人月程度）を受託するビジネスとする場合、AWS上に「多層アプリケーション（Web層、AP層、DB層）に即したインフラ環境を構築する」ことが多いと思います。 多層アプリケーションの構成例 このような構成をシステム毎、顧客毎に構築することになりますが、AWSで構
一歩進んだITエンジニアになるために クラウド環境が技術者のアジリティを高めているのを象徴するかのように、昨今は関連する新しいツールや、 活用⽅法が毎日のように話題になっています。こうした激変し続けるITトレンドの中から、技術者は真に⾃⾝の業務を変革するものを探し続けており、 情報交換と人脈構築の場が求められています。これらの意欲と活動に応じるため、ITに係るエンジニアの知的興味を満足するための夏の祭典として 「最高のITエンジニアリングを身につける！」をスローガンに当イベントを開催いたします。 KEYNOTE SPEAKER Preferred Networksの機械学習クラスタを支える技術 大村 伸吾 Engineer, Preferred Networks, Inc. Preferred Networksでは多くの機械学習の負荷を効率よく計算させるためにの機械学習向けのジョブクラスタ
分散システムについては、もう随分と前から学びたいと思っていました。ただ、それは一度首を突っ込んだら最後、ゴールのない迷路に迷い込むようなものなのです。どこまでも続いているウサギの穴のようなものです。分散システムに関する文献は星の数ほど存在します。様々な大学からたくさんの論文が発表されているばかりでなく、膨大な数の書籍もあるのです。私のような全くの初心者には、どの論文を読んだらいいのか、どの書籍を買ったらいいのか、見当もつきません。 そんなとき、一部のブロガーが、 分散システムエンジニア （それがどういう意味であれ）になるなら知っておくべき論文というものを推奨しているのを見つけました。その一部を紹介しましょう。 FLP , Zab , Time, Clocks and the Ordering of Events in a Distributed Systems , Viewstamped
1. Copyright © NTT Communications Corporation. All rights reserved. 1 ⼤大企業で実現するイマドキの内製開発 NTTコミュニケーションズ株式会社 技術開発部 岩瀬 義昌 2015年年7⽉月29⽇日 【A-‐‑‒5】【ユーザ企業登壇！】先進企業が語る、 ソフトウェア開発環境のビフォーアフター 2. Copyright © NTT Communications Corporation. All rights reserved. 2 ■名前 岩瀬 義昌 / @iwashi86 ■仕事 NTTコミュニケーションズ株式会社 技術開発部 Webコア Technology Unit Web/インフラ エンジニア ⾃自⼰己紹介 ■コミュニティ活動 ・WebRTC Meetup Tokyo
伊藤直也氏が語る、モダンなWebテクノロジーに共通する傾向とは？（前編） Chef、Docker、MicroservicesからReact、FRPまで。QCon TOkyo 2015 最新のITと関連技術をエンジニアの視点で掘り下げるイベント「QCon Tokyo 2015 Conference」が4月21日に都内で開催されました。 そのセッションの1つとしてKAIZEN platform Inc.の伊藤直也氏が行ったのが、「モダンWebシステム開発」と題して、最近のWebアプリケーションに関する技術に共通する傾向を探った講演です。 ChefやPuppetなどによるInfrastructre as CodeからImmutable Infrastructureなどのインフラ周りからReactなどのフロントエンドにまで共通する考え方とは何か、示唆に富むその内容をダイジェストで紹介します。 モダ
お探しのページは見つかりませんでした。 アクセスしようとしたページは削除、変更された可能性があります。
事前に断っておくがここでいう「インフラ」はレイヤ的には OS より上の話。 少し前に GitHub 時代のデプロイ戦略 - naoyaのはてなダイアリー で、GitHub を介したデプロイを実践しているということを紹介した。普段の開発を Pull Request ベースでやっているので、デプロイもまた Pull Request を契機に実行させると色々捗る、という話。 このプラクティスの対象領域をインフラにまで拡大してみました、というのが今回の話。 DNS レコードを Pull Request を merge した契機に自動で更新 AWS を利用している場合、ドメインの管理も Amazon Route 53 を使うといろいろと都合がいい。 Route 53 での DNS レコードの更新はこれまでブラウザから操作していた。これだと誰がいつ作業したかわからないし履歴もトラックしづらい。また変更
Docker で開発環境を作る話 こんにちは、Docker 0.9 が出ましたね。 ちょっと Docker を触っていて幾つかアレな点があったので共有しておこうと思います。 その他も合わせてまとめてます。 私の Docker TIPS Docker を使って開発環境、および開発環境の土台を作る まあよくある Docker の使い方って nginx だの redis だのいろんなサーバーを構築する感じだと思いますが。 今回は開発環境を構築する話をしたいと思います。 よく dotfiles なんかを github においてーなんてことやってる方多いと思います。 もうここは思い切って Docker のイメージにしてしまいましょう。 利点 モテる なんかイケてる感じがする 案件、プロジェクト毎に個別環境をクリーンなまま維持できる みんな同じ環境で作業することができる（ライブラリのバージョンなどが揃
2014年になって、ITの地殻変動がどこに起こっているのか、を考えてみる。 ＃ラフなメモ書き。 【1】最近感じることは、Webアプリをプログラミングするアプリケーションエンジニアよりも、サーバー基盤を構築するインフラエンジニアの方が目立つというか輝いて見える時が多い。 何故なのだろう？ また、先月の日経BP主催のITアーキテクト カンファレンスでは、エンタープライズシステムの構築に携わるITアーキテクトを対象にしているが、その内容はすべて、クラウドがキーワードだった。 DOAやOOAは全く含まれていない点が衝撃だった。 ITアーキテクト カンファレンス 2013 最近の流れを見ると、アーキテクチャ設計の技術では、DOAやOOAは既に古い技術であり、クラウドが席巻しているように見える。 【2】最近のバズワードである「クラウド」には、否定的な意見を持つ人も多い。 ITの歴史の延長線上にあるだけ
開発環境は難しい 最適な開発環境をつくるのっていつも難しいなーと思います。サーバ側に入って開発する人もいれば、クライアント側のIDEあげてる人もいるわけで人それぞれです。 その人に特化した開発環境をつくるだけであればそこまで難しい話ではありませんが、チームでの開発となるとそのあたりをうまく解消するのがだんだん難しくなってきます。また、新しくサブドメインが増えたりなど開発環境も常にアップデートし続ける必要があります。 このあたりを、サーバエンジニアが手動でやってると死にます。悪しきDev/Opsの対立関係がうまれてしまうので、なんとかしないといけない。 というわけで、オフィス移転をきっかけに開発環境を作りなおしてみました。以下の3点からさくらVPSを選びました。 コストを抑えたい 最近さくらVPSに東京リージョンができた ローカルネットワーク接続できるようになった 新規開発環境をつくる上での
7. 自己紹介 名前：長谷部 光治（インフラエンジニア） ・2012年2月 サイバーエージェント入社 ・今まで：一貫してクラウドシステム構築 2012年2月 〜 6月 OpenStack検証、導入 2012年7月 〜 現在 プライベートクラウド開発 ・現在：インフラ3割、開発7割 7 copyright(C) 1998-2013 CyberAgent, Inc. All rights reserved
(Monitoring Casual Talk in Kyotoで発表してきたので、ブログエントリにまとめ直しました) 2013年はインフラ周りの技術的な進化が大きく、いくつかのエポックメイキングな概念と実装が産まれました。個人的には特に以下の2つが大きいと思っています。 AWSの本格普及期 DockerとImmutable Infrastructure これらを踏まえて、2014年のウェブシステムの進化の方向性を考えてみます。また、それによるモニタリングへの影響もあわせて考えます。だいぶ長くなってしまったので、急ぐ人は最後に結論をまとめましたので、そちらからどうぞ! 2013年という時代背景 AWSが本格普及期を迎えているのは、言わずもがなのことで、Re:Inventでの246件という膨大のセッション数などにその勢いが表われています。 また、DockerはLXC (LinuX Conta
■プログラミングを始めたきっかけ なぜプログラミングを始められたのでしょうか？ 久保 達彦さん（、以下久）： 小、中学校ぐらいのときにWindows95が大きなニュースになったんですが、これからコンピュータの時代が来るんだろうなと思ったことが最初のきっかけですね。その後入学した大学でコンピューター部に入部してそこでプログラミングがどういうものなのか知りました。大学ではあまり実践的なことはあまり学べなかったので、コンピューター部の仲間と勉強会を開催したり、自分で買った技術書を読んで勉強していましたね。 ■新卒ではウノウに入社、フロントエンドからバックエンドまで、あらゆる業務を担当 新卒ではウノウに入社されたとお伺いしたんですが、ウノウではどういう業務を担当されていたのでしょうか？ 久：入社して始めの頃は「映画生活」というWebアプリケーションを僕を含めて3人のエンジニアで開発していました。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
