【1月23日追記】12月23日、24日に発生しました障害に関するご報告
いつもSkebをご利用いただき、誠にありがとうございます。 12月23日12時よりskeb.jpにアクセスできない大規模な障害が発生しておりましたが、12月24日07時に復旧いたしました。 12月23日、および12月24日が納品期限のリクエストは納品期限を12月25日23時59分までに延長させていただきます。 みなさまには多大なご迷惑をお掛けしましたことをお詫び申し上げます。 本障害につきまして詳細をご報告させていただきます。 概要日時: 12月23日12時22分〜12月24日7時00分 (JST) ダウンタイム: 18時間38分 内容: skeb.jpにアクセスできない不具合 原因: SkebはすべてのサーバとシステムをHerokuに設置していたが、障害発生時刻より同サービスのアカウントが理由の通知なく利用できなくなった。 解決: Herokuの一切の利用を中止し、すべてのサーバとシステ
Product Manager vs Product Owner
“What is the difference between a Product Owner and a Product Manager?” It’s an interesting question and one that takes time to unpack. Let’s look at where these terms and disciplines originated from and how some common frameworks explain them. When I started my career, I was called a Business Analyst. I did very little “business analysis” as we would look at it in traditional IT companies. Honest
完全マネージドな k8s ! GKE Autopilot を解説する
Kubernetes / GKE ファンの皆様こんにちわ。Google Cloud の Kazuu (かずー) です。GKE Autopilot が GA になりました。弊社公式ブログに続きまして、GKE Autopilot を日本語で解説していきたいと思います。 本記事は以下、3 部構成となります。 GKE Autopilot 概要GKE Autopilot を試してみるGKE Autopilot がハマりそうなユースケースは？ 1. GKE Autopilot 概要GKE Autopilot は GKE の新しいモードです。Control Plane に加えて、Node が完全マネージドになります。これまでの GKE では Node はユーザー自身が必要台数分作成し、以後の Day 2 オペレーション (e.g. アップグレード) 等も気に掛ける必要がありました。GKE Autopil
gRPCが遅すぎる？eBPFでカーネル内で動かす！
gRPCの高速化への飽くなき追求（具体的な目標や目的なし）を続けてきましたが、まだ、遅すぎる！今回は、安全にLinuxカーネルに機能を追加できるeBPFという仕組みを使って、カーネル内で動作するgRPCサーバを実装しました。その結果、前回実装したRust版よりも2倍高速になりました！ eBPFで安全なユーザコード実行eBPFを使えば、システムコール、パケットの受信など、カーネルで発生する様々なイベントに対して、私たちユーザが実装したコードを、カーネル内部で実行することができます。同じようにカーネルに機能を追加できるカーネルモジュールと違って、eBPFは、データ破壊など、システムの安定性に深刻な影響を与える危険なコードの実行を防ぐことができます。 eBPFで検索すると、たくさんの日本語の情報が見つかるXDPは、ネットワークインターフェイスのドライバのパケット受信時に、ユーザコードを実行する仕
【いでよ障害対応太郎】我々はインシデントにどう向き合っているのか 〜社内向け障害対応リスト付き〜
「なんかアプリでインシデント起きてエンジニアがどこかで対応してるらしいよ」 「インシデント時のお知らせって誰がどうやって出すんだっけ？」 「インシデントの復旧作業って今どれくらい終わってる？」 「あのインシデントって振り返りしたっけ？」 「似たようなインシデント、前も対応したような、していないような」 このような会話に覚えはありませんか？ FiNC Technologies社 (以下FiNC) では今まで インシデント対応をしていても自チーム内で対処しようとしてしまい、他の人が気づけないインシデント対応の仕方にフォーマットがなく、迅速な対応やお客様への報告ができないインシデントの振り返りが実施されず、インシデント時の知見が共有されないという問題がありました。 それらの問題を 気が付きやすく、シェアしやすくする = 統一のチャンネルで情報を整理し、そこにシェアしやすい空気を作る何をすべきかわ
SaaSで使える！プライシングの心理テクニック7選
「プライシングはサイエンスとアートの融合」これは私の前職のBCGで働いていた頃に、とある上司から言われた言葉だ。言葉の通り、プライシングはvalue-based pricingにしろ、cost-plus pricingにしろ、サイエンスな部分がよく強調される。しかし、プライシングは極めて戦略性の高い、アートな部分があることを忘れてはならない。価格はその企業のポジショニングを語る強力なマーケティングメッセージであり、それに消費者心理がどう動くかは、数字では予想し切れない。 J.Cペニーのプライシングの失敗(2012年) いかにプライシングのアートの部分が重要か、米百貨店大手 J.C.ペニーの失敗例を紹介する。J.C.ペニーは競争の激しい小売において、自社の業界でのポジショニングの見直しを2011年から始めた。その一環として、従来の小売で用いられるような、年中やっているセールやクーポンを一切排
ミルクボーイがアジャイルを説明したら
序章駒場「最近、うちのおかんがシステム開発に興味を持っててなぁ、名前は忘れたらしいんやけど、迅速に開発できて、仕様変更にも対応できる、素晴らしい開発手法を取り入れてるところがあるらしいんやわ〜。」 内海「そんなもんアジャイルに決まってるがなぁ〜! 今やシステム開発と言えば、アジャイル。素早く変化に対応できるってゆーのが特徴なんよ。そもそも名前が “迅速” を意味する英語やねんから、アジャイルに決まってるがなぁ〜。」 チームの人数駒場「最初、オレもそう思たんやけどな、なんでも 40 人ぐらいで開発してるらしいんやわぁ〜。」 内海「ほなぁ、アジャイルちゃうかぁ…。アジャイルでは 5〜9 人ぐらいが推奨されてるからなぁ〜。40 人もおったら、とてもやないけど、コミュニケーションが成立するとは思われへんなぁ〜。効率の悪い伝言ゲームになるのは目に見えてるからなぁ〜。おかん、他にもなんか言うてなかった
Uber Execs Konmari Their Org, Lay Off Employees That Do Not Spark Joy
1455 MARKET STREET, SAN FRANCISCO — On a cloudy night in San Francisco, barely a week after their IPO, a group of Uber execs gathered in a conference room to KonMari their orgs by laying off employees that did not spark joy in their lives. The executives were seated together in a conference room with frosted glass walls. At the front of the room, a screen displayed the profile of an employee with
データ指向アプリケーションデザイン
AmazonでMartin Kleppmann, 斉藤 太郎, 玉川 竜司のデータ指向アプリケーションデザイン ―信頼性、拡張性、保守性の高い分散システム設計の原理。アマゾンならポイント還元本が多数。Martin Kleppmann… 手軽に扱えるデータの量や種類が増える一方、CPUの性能はムーアの法則通りには成長しなくなり、大規模データ処理では、多数のマシンを活用する分散処理が欠かせなくなってきました。クラウドの普及とともに多数のマシンを自ら調達せずとも分散システムを構築できるようにもなっています。 しかし驚くべきことに、今までこの分野に入門するための定番の書籍がありませんでした。分散処理にデータ処理が加わる融合分野である上、オープンソースプロジェクトの進化も速く、専門家同士でも共通の理解を構築するのが非常に難しかった分野です。この本を上手に使うと、既存のOSSプロジェクトの位置付けや、
Docker 19.03新機能 (root権限不要化、GPU対応強化、CLIプラグイン…)
NTTの須田です。2019年7月23日に公開された、Docker 19.03の新機能をお伝えします。2018年11月8日にリリースされたDocker 18.09以来、8ヶ月ぶりのリリースです。 root権限不要化従来のDockerは、ホストのroot権限でデーモン(dockerd)を動作させる必要があったため、脆弱性や設定ミスを突かれると、ホストのroot権限を奪われる恐れがありました。 Docker 19.03では、非rootユーザでデーモンを実行できるようになりました(Rootlessモード)。 Rootlessモードを有効化することで、万一Dockerに脆弱性や設定ミスがあっても、攻撃者にホストのroot権限を奪取されることを防ぐことが出来ます。ただし、現時点ではcgroupを利用できないなどの制約があります。 RootlessモードのDockerは， curl -fsSL http
Goodbye Amazon!
(English follows Japanese) 1月末で5年間勤めたAmazon Web Services Japanを離れ、新しいチャレンジをすることにしました。まずは今まで関わった全ての人、特にお客様・パートナー様、最後にAWS社員の皆さんに深く感謝をしたいと思います。ありがとうございました。この5年間を振り返ると、本当にあっという間で今でも初日のことをよく覚えています。当時はメンバーも片手で数えるほどで、まだ何も出来上がっていない・全部一から作り上げなくてはいけない、そんな状況でした。そこから早くも丸5年が経ちますが、私自身掛け替えないの貴重な経験と喜びを得ることが出来ました。特に日本の中だけで閉じていた自分にとってはグローバル企業のダイナミズム・スピード・スケールの大きさ・価値観などに触れることができたのは本当に貴重だったと今振り返って感じています。 あまり過去を振り返らない
Google Cloud Next 2019 in SF , DevOps関連発表まとめ
Google Cloud Next 2019 in San Francisco が 2019 年 4 月 9 ~11 日に開催されました。その中で、DevOps 関連の発表をまとめました。 Cloud Code for IDEsCloud Code を利用することで、クラウドネイティブアプリケーションを、より速く、より簡単に、開発・デプロイ・デバッグすることができます。Cloud Code for VS Code (Beta)、Cloud Code for IntelliJ (Alpha) で利用可能です。 コンテナを使ったアプリケーションを開発する場合、ソースコードを編集するたびに、コンテナのビルド・デプロイを繰り返す作業が頻繁に発生するため、開発以外の作業に多くの時間を取られてしまいます。 Cloud Code を利用することで、ソースコードの変更を自動的に検知し、本番環境へのデプロイ
Google Cloud Next 2019 in SF , サーバーレス関連発表まとめ
[18 分 20 秒 ~] Cloud Runの概要とデモ、特に [34 分 00 秒 ~] のオートスケーリングのデモはCloud Runの優位性が分かる内容ですさらに Cloud Run に全振りしたセッションとしては以下がオススメです。Cloud Run のリソースモデルや、またCloud Tasks や Cloud Scheduler との連携、さらに具体的なユーザー事例まで盛り沢山です。また、このセッションを見る限り東京でも Cloud Run がすぐに使えるようになりそうです。 [36 分 50秒 ~] VELOLIA 社の事例紹介現状は何に使えそう？Knative をベースにしているものの、今のところ Eventing は Cloud Run と Cloud Run on GKE 両方ともにサポートされておらず、当面は Web や API をホストする環境として使うことになる
Cloud Run を最速で触ってみる
Cloud Run とはGoogle Cloud Next 18では serverless containers on the Google Cloud Functions infrastructure + GKE Serverless addonと説明されたものですね。 早速、こちらのQuickStartやってみましょう 事前に必要なことプロジェクトを作成する（既存のプロジェクトを利用することもできます。終了後の後片付けを考えると新しくプロジェクトを作っても良いです）プロジェクトのbillingを有効にするCloud Run APIを有効にするCloudSDKのインストール済み/設定済みであることcomponentsのupdateと、beta componentsのinstallが必要です。コンポーネントをupdateするgcloud components updatebetaコンポーネ
Kubernetesでステートフルなゲームサーバを動かした思い出
とあるスマートフォン向けMMORPGのプロジェクトで、アプリケーションサーバをほぼすべてGKE(Google Kubernetes Engine)に乗っけて動かしていました。 このゲームは、モバイル向けながら、複数プレイヤ間でそこそこリアルタイム性の高い同時プレイができるものでした。同じフィールドを誰かが歩けば、自分が見ている画面でもほぼ同時にそいつが歩いて横切っていく、同じ敵と皆で一緒に戦えば、誰かが繰り出した攻撃が参加者全員の画面に即同期される、もちろんチャットもできる、そんな具合です。今ではさほど珍しくないのかもしれませんが、PCのオンラインゲームのような機能を搭載した、リアルタイム性の高いモバイルゲームでした。 さて、こうなってくると、オーソドックスなWebサーバのような、HTTP/1でリクエスト/リプライを捌く、というサーバだけでは要件を満たすことができません。 複数プレイヤ間で
私はこうやってGoogleに入りました（Reiko編）
きっかけ私はグーグルに入るまで、情報系のしがない研究者としてポスドク的な仕事をあちこちでやってました。それで研究者データベースに名前が載っていて、女性なこともあり、グーグルのリクルーターさんが面接のお誘いのメールをくれたのがきっかけです。ちょうど、研究というより企業の開発寄りの仕事もやってみたいと思っていたタイミングだったので、グーグルという選択肢があるのか！行けたらスゴイ、面白そう、と思いました。 プログラミングスキルは？プログラミングは仕事用のコードを自己流で書きちらかしてるだけだったのでコーティングには全く自信がなく、そのリクルーターさんからいくつか資料が送られてきたので、参考にして勉強しました。Cracking the Coding Interview、プログラミングコンテストチャレンジブック、あといくつかアルゴリズムの本（思い出したら書きます）などをやりました。 リクルーターさん
自分がGoogleに入った時の話
自分がGoogleに入った時の話 はじめてこの社名を知ったのは、高校生の時。自他共に認めるパソコンオタクだったぼくは書店で月刊アスキーを立ち読みしていた。そこで、新しく登場した検索サービスについて丸々1ページ使って紹介されていた。その速さの秘密は、インターネット全体をメモリに載せて処理をしているかららしい。信じられない量のメモリを持っている謎の会社。それがGoogleをはじめて知った瞬間だった。 大学は東大に進んだ。志望した主な理由はお金がある大学だと聞いたから。なぜお金が大事か？それはお金がないと速いコンピュータが買えないから。高性能なコンピュータが使いたかった。幸い無事に入学でき、その後無事に志望していた理学部情報科学科に進学した。そこには数百台程度のクラスタがあって、それらを使って友人らとオセロのAIの開発を競った。なぜそんなことを熱心にやっていたのか正直わからない。自分にとっては小
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Product Owner vs Product Manager
5 Differences between EKS and OpenShift
As of 2019/4 Kubernetes CSI について