セキュアな GKE クラスタを構築するために知っておきたいポイント 2022 年夏（前編）
はじめにKubernetes クラスタやその上で動くワークロードに対する脅威は多様化しており、クラスタ コンポーネントだけではなくコンテナ アプリケーションやソフトウェア サプライチェーンも含めた多層的な防御が求められます。 Google Cloud では Google Kubernetes Engine (以降 GKE) やその周辺エコシステムにおけるセキュリティ機能が活発に開発されており、これらの機能を上手く活用することで Kubernetes 環境の多層防御を実現可能です。 とはいえ、Google Cloud で提供している コンテナ セキュリティ関連機能 / サービスは種類が多すぎて何がなんだか分からない方も多いのではないでしょうか。本記事では、GKE 周辺のセキュリティ機能 / サービスの概要や使い所、おすすめの設定等について紹介していきます。 ちなみに本記事は Cloud Na
Google Cloud のコンソールや API へのアクセスをアクセス元の IP アドレスで簡単に制限する
こんにちは。Google Cloud Japan でカスタマーエンジニア（プリセールスエンジニア）をしている有賀です。 クラウドサービス利用のご相談に乗っていると、ときどき(しばしば？)、ウェブコンソール(クラウドサービスを設定するためのウェブページ。Google Cloud では Cloud Console と呼びます。)や、API へのアクセスをアクセス元の IP アドレスで制限したい、というご要望を受けることがあります。 インターネットでサービスを公開する際のアクセス制限として、ID とパスワードだけでは不安（パスワードが漏れたらアクセスされ放題に！）だから、追加でアクセス元の IP アドレスで制限する、というのはそこそこ一般的におこなわれていたかと思います。（ゼロトラストのアプローチもあると思いますが、それはまたの機会に。:-) こういった機能をオンプレミスで提供する場合は、ファイ
TCPが遅すぎる？QUICを使おう！
「それ、QUIC使えないの？」 それがなんであれ、QUICを使うことを主張することで、みんなが「なんか良くわからないけど、TCPを置き換えたほうがいいのかな？」と思うようになるはず。全てのアプリケーションを、TCPの代わりにQUICを使うように修正するとなれば、この先10年間ぐらい、エンジニアみんなの仕事を作ることができます。業界愛ですね。 すでに、SSHやDNSのQUIC対応は始められています。既存のアプリケーションをQUICに対応させる難しさを調査するために、RustでBGP over QUICを実装してみました。 QUICの実装QUICは、TCPと同じく、パケットの再送、輻輳制御など、信頼性のある通信を実現するトランスポートプロトコルです。実装面の大きな違いは、TCPがオペレーティングシステムのプロトコルスタックの一機能として実装されるのに対して、QUICはアプリケーションで実装され
新社会人のみなさんへ
VOYAGE GROUP -> New Relic -> Splunk, climber, skier, ajito.fm talker. My own view.
Wataが1万接続で動いた
Wata は 1:N で多人数に音声とデータを同期的に配信するための配信基盤です。詳細は Wataプロジェクトについて を参照して下さい。 このたび、Wata が無事 1:10000 の配信で動作しました。 構成は以下の通りです。 Wata サーバ: AWS の c5.xlarge (4コア) 1台受信側 Wata クライアント: AWS の c5.xlarge 2台（各5000接続ずつ）配信側 Wata クライアント: MacBook Pro の Unity Editor から配信この構成で、 配信側は48kHzで録音して送信するサーバでは Google の Cloud Speech-to-Text を行った結果をクライアントに配信するという条件で接続して、無事安定して配信できていることを確認しました。 この時のWataサーバの top はこんな感じです。 4コア中113%なので、約30
GoのAPIのテストにおける共通処理
GoのAPIを書くとき、参考になるユニットテストの話は非常によく見ます。Table Driven Testをしましょうとか、サブテストの実行とか、そのあたりの話はたくさん書かれています。 また、テストキャッシュなども出てきましたので、ユニットテスト周りの機能・ノウハウは充実していると感じてます。 一方で、httptestを使ってテストサーバーを立て、リクエスト/レスポンスの内容を検証する場合、単一のリクエストを検証する程度のサンプルにとどまっていたり、あまり共通でこういう処理を書いてるよ、みたいなノウハウがなく、自前で一から書くとなると非常に腰が重くなります。 事実自分はそういう経験をしました。そういった共通処理は普段internalパッケージの中の、testutilsとしてまとめる、などしています。 今回はGoで上記のようなテストを書く場合、どういう共通処理が必要となったかをテーマとして
FGO を支える負荷試験ツール
これはアカツキとディライトワークスが共同で主催している “FGOなど大規模ゲームの課題から学ぶゲームサーバ・インフラ勉強会” での LT 発表資料です。こちらの資料に軽く補足を入れながら話をしていきます。 時雨堂では FGO の検証に利用するための負荷試験ツールを提供しています。 先日、大きめのメンテナンスが無事終わり、ほっとしています。 さて、メンテが無事終わって、FGO の中の人から以下のようなありがたいメッセージをもらいました。 負荷試験ツールなくしては今回の改修はなしえなかったと思いますので本当にありがとうございました…。その負荷試験ツールがどんな仕組みで、どんなことを実現しているのかを書いていきます。時雨堂が負荷試験ツールで実現したことのみを書きます。 主に技術的な話というよりはこんなことやったよがほとんどです。 本番データを利用した負荷試験利用されている負荷試験ツールは、時雨堂
From Monolith to Microservice Architecture on Kubernetes, part 1 — The Api Gateway
In this blog series we’ll discuss our journey at Cupenya of migrating our monolithic application to a microservice architecture running on Kubernetes. There’s a lot of talk on microservices and also a lot of great online resources available, but I noticed that practical & pragmatic guidance is often lacking. Therefore, I’ll try to get really hands on. If you’re unsure what a microservice is, I sug
なぜNYAGOをクローズしたのか – kenji watanabe – Medium
クローズしようと思った理由・ Android非対応によるユーザーの取りこぼしが多い。対応したいが取りかかれていない、時間がすごくかかる。プロモーションなどの無駄が多い。 ・開発の環境が整っていない、スピード感が足りない。それによって施策が打てない、飽きられてしまう危険性が高い。 ・サービスが提供できる価値（ニャゴできたという体験）を消費していて、天井が見えている。NYAGOで仲良くなったらLINEなどの他のサービスでやりとりをしてしまうのも問題。現状の形だと継続して使ってもらえないと判断。 ・ニャゴされるにはSNSで募集しないといけないのが面倒だし毎回投稿するのはダサいなどのネガティブな印象。最初Twitterで流行っている感を出したくてこの仕様にしたが、次からはアプリ内からニャゴできるようにしたい。Twitterで見つけてニャゴするのではなく、暇なときにNYAGOアプリを開いてニャゴする
Erlang/OTP と Lua で負荷試験ツール (2)
負荷試験製品の骨組みができてきた。今回はアーリーアダプターとしての顧客が数社いるため、まずは動くものを優先に作っていってる。 負荷試験ツールこの製品は使うときだけ起動するというよりは、常時起動しておき、HTTP API 経由で好きなタイミングで使える負荷試験ツールとして開発している。 負荷試験は準備が面倒だったりするため、しっかり計画を建てて行うというのがよくあるが、これはできるだけ気軽に負荷試験を行えるのを目的としている。 全体構成今回の全体構成図を起こしてみた。 Web API での負荷試験の世界では仮想ユーザ (VU) というのが標準らしいので真似をすることにした。 登場人物は master と worker と vu の 3 種類。 master は worker の管理worker は VU の管理VU は Lua を実行する 1 仮想ユーザmaster は常時起動しており、wo
KubeCon2017感想: Kubernetes in 2018 – deeeet – Medium
先週12月6日から8日にかけてTexas Austinにて開催されたKubeCon + CloudNativeCon2017に参加してきた．具体的なセッションの内容などはMercariのTech blogに上がると思うのでここでは簡単に自分なりの感想と概観をざっくりと吐き出しておく． KubeCon 2017の3日間と今後のKubernetesの（大きな）展望は2日目のClayton Coleman氏によるKeynoteのWhat’s Next? Getting Excited about Kubernetes in 2018が総括をしていると思う．自分の今取り組んでること，今後取り組みたいこと，も結局これに集約されていると思う．この発表の中で今後，特に直近の2018年に，k8sでフォーカスが当てられると述べられていたのは以下の7つの分野である． The year of service m
Apache Kafkaを使ったアプリ設計で反省している件を正直ベースで話す
Apache Kafka: Producer, Broker and Consumer2017年は生まれて始めてApache Kafkaを本格的に業務利用（PoCではなく本番運用）した年でした。Apache Kafka的なメッセージングミドルウェアそのもののは、社内的な事情でよく使っていたのでその使い勝手に対して困惑はほとんど無かったですし、ミドルウェアとして非常に安定しているため、Kafkaクラスタそのものでの不具合らしい不具合が発生したことは一度もありませんでした。 しかし、Kafkaのトピック設計などに関してのベストプラクティスは事例ベースでもあまり見かけたことがなく、チームメンバーと悩むことも多かったです。このストーリーでは、主にKafkaを利用したアプリ設計で考えたことや失敗したことを振り返りつつ共有します。なお、パーティション数や各種バッファサイズなどのチューニング要素は今回取
ある子育てエンジニアの一例
自分には子供が3人います。幼児が二人、乳児が一人（全員♂）。妻は働いていて、それぞれの子供が生まれて比較的すぐ職場復帰してます。三男の時にいたっては、彼が生後3ヶ月になる直前に職場復帰しました。 自分は基本的に朝8時半頃から仕事を開始し、4時に帰宅して、そこから父親業務をします（詳しくは数年前のこのエントリを参照）。そこで一日が終わりだと「あ、時短勤務なんですね」で終了なのですが、さすがにそれでは色々やるのに時間が足りない。自分はイベントの主催とかをやったりしてますし、それに通常業務もいくら午前中に気合いを入れて進められるだけ進めてもさすがにもう少し仕事をがんばらないとまわらないのです。なので夜に仕事ができる、ないし次の日のための余力を作るための時間を持てるというのはとても大事なのです。 幸い今のところ自分は子育てで忙しいなりにこうやってブログを書いたり、夫婦ともお互いに一人だけの時間を作
Goのパッケージ構成の失敗遍歴と現状確認
この記事は Gunosy Advent Calendar 2017の5日目の記事です。前回の記事はGunosyのパーソナライズを支える技術 -ワークフロー編-でした。 GoでAPIを書くときの問題僕の在籍するGunosyはGoを昔（？）から本番採用しておりまして、ノウハウも潤沢に溜まっている企業だと言えます。 しかし、contextの扱いやベストなパッケージ構成、テスト、net/httpでAPIを書くノウハウなどなど、迷うことは多々あります。 これは弊社特有の事情ではなく、Goのサーバーサイドエンジニア全員にとっての問題です。中でも、パッケージ構成をどうすればいいのか（相互参照せずに快適に開発を進められるパッケージ構成とは）を見つけるのは結構難しく、各々のチームにお任せ、という状況です。 今回は上記の問題のうち、パッケージ構成に踏みこんで見たいとおもいます。会社でもよくパッケージ構成をどう
Docker Cheat Sheet
DisclaimerThis content is part of / inspired by one of our online courses/training. We are offering up to 80% OFF on these materials, during the Black Friday 2019. You can receive your discount here. I’ve been using Docker for years now, in my previous professional experiences and for my company (eralabs.io) customers and I wanted to share my knowledge, that’s why I started Painless Docker Course.
ソフトウェア開発で学んだが使わなかったもの
開発手法など、一通り学んだが実際に使っていないものは多少なりあると思う。それらについて掘り起こしてみたい。 スクラム開発認定スクラムマスター研修には研修会場ホストという立場で数回立ち会った。認定外の研修も幾つか受講した記憶がある。書籍もそれなりに読み、Scrum Gathering Tokyoなどのコミュニティにも顔を出し、まあそれなりに色々考えて捉えてきた。でも、自分のチームでは使っていない。スクラム開発というアイデアに矛盾があるからだ。 そもそもスクラム開発ではチームの自律的な行動を良しとしており、それに対する”フレームワーク”を提供しているということになっている。イテレーション、バックログ、ふりかえり、デイリーミーティング（いまだに「朝会」って言ってる人いないよね？）、そしてそれらのお作法。誰が言ったかわからないが、それぞれの作者の意図を察するためには「守」が大事らしい。守破離の「守
kazeburo/choconと、それを支えるnet/httpの実装について
【資料公開します】AWS Dev Day Tokyo 2017 にて登壇しました／choconの簡単なご紹介 - Mercari Engineering Blog こんにちは。SREの @ kazeburo です。2017年5月31日から6月2日にAWS Summit Tokyo 2017と同時に開催された「AWS Dev Day Tokyo 2017」に登壇しました。 登壇する機会をいただき、ま… 先日、というか昨日、この資料が流れてきまして、Private Networkの外部との通信を効率良く行うためのミドルウェア、choconというproxyサーバーが紹介されていました。SSL, HTTP/2を加味した上での超シンプルで高速なforward proxyサーバー実装という印象です。 使い方やAPIの叩き方は上記のリンクを参考にしていただくとして、やたらマイクロな実装でなぜこうも高速に
Lua lint “luli” のソースコードを公開しました
Lua 言語用のソースコード静的解析ツール luli の販売終了に伴い、ソースコードをオープンソースで公開しました。製品版をベースにしていますが、ソースコードも機能も同一ではありません。実はこれが今後 WebRTC 製品を主力に据える会社の最初の製品です。 開発・販売を終了した理由は二つあります。一つは「売れなかった」、もう一つは「リソースが足りない」です。ただ、会社として「製品がある」ことを重視していたので、売上は最優先ではありませんでした (売れるに越したことはありません) 。問題は「リソースが足りない」です。 luli は私一人で開発していたために専従は難しい。かと言って他の人を巻き込めるリソースもないし、何よりコストとリターンが釣り合いません。 それはともかく、せっかく OSS にしたのでよければ使ってみてください。 OCaml のビルド環境を一から整えるのは大変でしょうから、ビル
56歳からコードを書き始めて食べていく方法
私は56歳、最近プログラミングを始めたんだ。 なぜかって？やりたいからに決まっているじゃないか。ようやく最近コツをつかめてきてね。でもコツをつかめたからといって簡単にはいかない。正直なかなか手こずっている。でもいいんだ。 アルゴリズムに挑戦して我を忘れるのは楽しいし、まだテストしたい事があって「あと数分だけ」と繰り返し自分に言い聞かせるのもいい。「今度こそ上手くいったかも、、」とドキドキしてから「やったぞ！ついに動いた。」となる瞬間も大好きだ。 でもこんな私には今まで趣味と呼べるものが何ひとつなかった。自分に見返りがない事に時間を費やすのは嫌だったんだ。ただ楽しみのためだけに何かをするのが好きじゃなかったのさ。休みの日にやる事といったら、ちょっとした小遣い稼ぎになるような事ばかりだった。 オーケー。もちろんコーディングだって小遣い稼ぎさ。上手くやればかなり稼げる。これだってあなたから見れば
AWS BLOX vs Kubernetes
On the first of December Amazon launched BLOX a collection of open source tools for the EC2 Container Service. The idea here is to let you build container schedulers and integrate third-party schedulers like Mesos or Kubernetes with ECS. ESC also got update with affinity oriented scheduler. Overview of Amazon ECS + BLOXAmazon EC2 Container Service (ECS) is a highly scalable, high performance conta
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
