ベルギーの St. Ghislain にあるグーグルのデータセンターの冷却塔からの蒸気こんにちは、Google Cloud Platform (GCP) でネットワークプロダクトを担当しているカスタマーエンジニアの有賀です。この記事ではクラウドとオンプレミス環境の間や、クラウドとクラウド間のハイブリッドネットワークを構成する時に便利な GCP のサービスをご紹介したいと思います。 TL;DR (というか目次)GCP にはオンプレミス環境とクラウドのハイブリッド環境や、他のクラウドとのマルチクラウド環境を、簡単・効率的に作れる色んなサービス・機能があるので、以下のようなサービス・機能をさくっと(?)ご紹介します。 Cloud VPNVPC ルーティングモードVPC ピアリングカスタム経路 import/exportPrivate Google Access for オンプレミスホストDNS

このルーターの先は Google Cloud につながっているというイメージ図TL;DRこの記事では、個人でも安価に手に入れられる高機能ルーター EdgeRouter X を使って、自宅ネットワークと Google Cloud の VPC を Site-to-Site VPN でつなぎ、手元の PC からプライベート IP 経由で Cloud SQL インスタンスに接続するまでの道のりを紹介するものです。 はじめにこの記事は、Google Cloud Japan Customer Engineer Advent Calendar 2020 の 17 日目の記事です。（間に合っていれば・・・） こんにちは、Google Cloud で Data Management Specialist というロールをやっている佐藤です。データ マネジメントってデータ管理？具体的になにやってんの？って感じの

この記事は Google Cloud Japan Customer Engineer Advent Calendar 2020 の 20 日目の記事です。 皆さん、こんにちは。Google Cloud の内間(@kuchima)です。本日も前日の Kozzy さん(Kozzy Hasebe)に引き続きみんな大好きサービスメッシュネタです。 この記事では、Google Cloud が提供している Traffic Director というサービスを利用したプロキシレス サービスメッシュ（以降、プロキシレス gRPC と記載します) の概要について説明していきたいと思います。 サービスメッシュとは？という話についてはこちらの記事では触れないので、Kozzy さんの記事「Anthos Service Mesh を導入、移行、そして使いこなしてみよう」をご参照ください。 Traffic Direct

こんにちは。インターン生の富田祐永です。普段は情報系の研究室で超伝導量子コンピュータの研究をしています。 2022年1月から約1ヶ月間、NTT 研究所で「コンテナランタイムの実装及び評価」というテーマのインターンに参加させていただいておりました。 インターン参加経緯改めて軽く自己紹介をさせていただきます。 私は今は修士1年の院生なのですが、実は学部時代は情報系ではなく経済学部にいました。また、趣味で何かやっていたというわけでもなかったため、特に低レイヤに関しての実装経験はほぼ皆無です。 院に入ってからも、研究の傍らでちまちまCのコンパイラを書くくらいしか余裕がなく、何か面白いものを集中して実装できる期間が欲しいなあと思っていました。そのため、今回のテーマの募集を見つけた瞬間「これだ！」となって即応募しました。 取り組んだテーマさて、自分が取り組んだのは「containerd-shim-ru

はじめにNEG (Network Endpoint Group) というと Container-native Load Balancing の文脈で話されることが多く、パフォーマンスを向上させるためのものという認識が強いと思います。もちろん結果としてパフォーマンス向上が見込まれる場面もあると思いますが、それと同じく個人的に重要だと思うのが、NEG には Kubernetes の世界とその外のプラットフォーム (GCP) を繋ぐ大事な役割があるという点です。 本記事では NEG とは何か、なぜ重要なのかというのを一から説明したいと思います。 尚、NEG には大きく分けて Zonal NEG と Internet NEG という2種類がありますが、本記事では Zonal NEG に絞って記載します。また Zonal NEG は VM を表すものとしても使えますが、ここでは GKE の文脈に絞っ

図1: QUICコネクションを振り分けるロードバランサはじめに本記事では、バックエンドのWebサーバへリクエストを振り分ける装置の意味でのロードバランサ(図1)について、QUIC対応の議論状況を紹介します。方式編と実装編にわけて二編を予定しており、本稿は方式についての解説です。 IETFでは、F5 Networksとマイクロソフトから提案されたロードバランシング方式が議論されています。本稿では下記のインターネットドラフトをQUIC-LBと表記します。 QUIC-LB: Generating Routable QUIC Connection IDs https://datatracker.ietf.org/doc/html/draft-ietf-quic-load-balancers 執筆時点の -07 をベースとしますが、ドラフトですので今後の議論次第で改版が続きます。あらかじめご承知おき

コンテナユーザなら誰もが使っているランタイム「runc」を俯瞰する[Container Runtime Meetup #1発表レポート] こんにちは、NTTの徳永です。本稿では、コンテナユーザなら誰もが使っていると言っても過言ではない、コンテナランタイムの筆頭「runc」に注目し、その概要を仕様と実装の両面から俯瞰します。本稿は私が主催者の一人として参加した「Container Runtime Meetup #1」で発表した内容をベースにしています。詳しい内容は発表資料もぜひご参照ください。 コンテナランタイムとはKubernetes等のコンテナオーケストレータを用いてアプリケーションをコンテナ(Pod)として実行するとき、実際にコンテナの作成をしているのは誰でしょうか。実はKubernetesはコンテナを直接触らず、あるソフトウェアを用います。まさにそれがコンテナランタイム（以降、ランタ

はじめに2021年7月12日にNgnixブログに掲載された記事 “Our Roadmap for QUIC and HTTP/3 Support in NGINX” では、QUICとHTTP/3機能を2021年末にはメインラインへマージする計画が言及されています。現在のHTTP3/QUIC対応Nginxは、専用の開発ブランチ (nginx-quic)で開発が進められていますが、常に最新のリリース (7月26日時点で1.21.1)を取り込んでおり、HTTP3/QUIC以外の最新機能も利用可能です。筆者も、昨年から開発ブランチの動作を試しており、HTTP3/QUICでの大きな負荷をかけても良好なパフォーマンスを示しています。 さて、Nginxブログで言及されたHTTP3/QUICに関する機能の一つとして、“eBPFを使ったマルチプロセスアーキテクチャ” という項目がありました。QUIC特有の仕

この記事は「Eureka Advent Calendar 2020」の19日目の記事です。 こんにちは、2020年今年こそはとダイエットに意気込み、振り返ってみればジムへ行ったのは1回きり、出前を頼んだのは100回以上、見事に5kg体重を増やした山下です。 昨日は同じBackendチームのJamesさんによる「Understanding Allocations in Go」でした。 今回はこちらの記事にあるPairsエンゲージのエラー機構を詳しく説明していきたいと思います。 （本当は面白Goクイズをたくさん出したかったのですが、playgroundをmedium上にうまく埋め込めず断念しました。泣） 概要errorsパッケージを作成して独自のエラー構造体を定義しましょうエラーは全ての箇所でラップして綺麗にスタックトレースを出力しましょうエラーレベルやエラーメッセージを付与して汎用性を高めて

Generic Snowflake functions to interact with web APIs directly from SQL statements. Photo by Alessandro Viaro on UnsplashSnowflake is an extremely SQL-friendly database: you can ingest, transform, and access your structured and semi-structured data directly from your SQL code. However, as a cloud-only data platform, it has some fundamental restrictions: all insecure operations like accessing local

新しいAPIが作られるたびに、私たちは、古いAPIを置き換えるだけで高速化という夢をみます。何度夢破れても、高速なAPIが追加されたと聞けば、試さずにはいられませんよね！ 今回は、Linuxカーネル5.1で追加されたio_uringを使って、Rustのasyncランタイムを実装し、gRPCサーバのベンチマークを実行してみました。 io_uringとはio_uringは、ファイルシステムとネットワークの非同期I/Oのために開発されました。同期よりも非同期のほうがおしゃれ、そういう雰囲気ありますよね！クラウドネイティブも、非同期にAPIを介して、なんかやってるやつですよね。 io_uringのインターフェイスは、高い性能を目指し、1）アプリケーションとカーネル間でのメモリコピーを避ける、2）複数のI/O要求を一度にカーネルに伝えることができる、という工夫がされています。 下図のように、アプリケ

夏のある日、GoのgRPCが、Rustよりも2倍早いという記事を見つけました。「おいおい、測定ミスだろ」と強がっていましたが、日々、不安は高まっていきます。真実の愛であれば、疑うことは許されませんが、エンジニアの言語への愛など、所詮、状況に応じて使い分けるような打算的な愛。確認してみました。 性能測定結果上記の記事と同じく、gRPCのサーバソフトウェアは、Goはgrpc-go、Rustはtonicのgreeterの性能を、gRPCのクライアントソフトウェアghzを使って、測定しました。ハードウェアは、AWSを利用し、サーバはc5a.8xlarge(32 vCPU/64 GiB)インスタンス、クライアントはc5a.16xlarge(64 vCPU/128 GiB)インスタンスを使いました。 1台のクライアントインスタンスは、同時に3,000個のgRPCクライアントを立ち上げ、合計で6,000

この記事はこの記事は Google Cloud Japan Customer Engineer Advent Calendar 2019 の 12日目の記事です。 はじめにGoogle Cloud Platform (GCP) でバッチ処理を起動するための以下のパターンについてご紹介したいと思います。以下、８パターンあげてみました。とはいえ、最後の3つは GCP のバッチスケジューリングという観点からは少し外れますが、バッチの起動時に使われるということでご容赦を。 Cloud Scheduler : フルマネージドな cron ジョブスケジューラです。フルマネージドという点が非常に大きなメリットであり、多くの処理を自動化し実行することが可能です。Google App Engine cron サービス : HTTP GET を利用して、特定の URLを呼び出します。Google AppEng

NTTの須田です．Moby (≒Docker)，BuildKit，containerdなど，コンテナ関連のオープンソースソフトウェアのメンテナ (開発委員．コミッタとも．)を務めています． 本記事では，2018年11月8日にリリースされたDocker 18.09の新機能を紹介します． BuildKitの正式統合Dockerfileからコンテナイメージをビルドする機能である，docker build の新しいバックエンドとして，BuildKitがDocker 18.06より実験的に採用されていましたが，Docker 18.09にて，正式な機能に格上げされました． BuildKitは，須田が2017年4月に提案した docker build並列化のpull requestを契機として，Docker社 Tõnis Tiigi氏の主導により，Moby傘下のオープンソースプロジェクトとして同年夏に発

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

こんにちは、こんばんは。CTO の kaneshin です。エンジニア組織のマネジメントに多く時間を割いていますが、技術的な方面では Go と GCP を掛け合わせて Nature Remo + Go + Cloud Functions + BQ を駆使して、部屋の温度・湿度・照度や人体センターの検知を趣味で少しずつ開発しています。 クラウドサービスをはじめとしたマネージドサービスが主流な界隈にとって、今までアプリケーションの責務として実装していたところをマネージドサービスに責務を委譲することができたりするので、アプリケーションを複雑に実装しなくて済むようになっていますし、保守・運用の観点からもそのような設計方針をよく目につくようになりました。 例えばバッチ処理でデータを ETL 処理の設計を責務分割するのは良い例でしょう。 Data Transformation with Cloud D

Photo by chuttersnap on UnsplashいつもはTerraformでAWS東京リージョンへの構築のみを行っていますが、仕事で複数のリージョンにも同一のインフラを構築する機会があったため、Terraformでマルチリージョンを試してみました。 使用したTerraformバージョンはv0.11.0になります。 マルチリージョン適用前既にTerraformにて、AWS東京リージョンへVPCやEC2などの構築ができている状態。まあ、よくみかけるケースかと。 ここから異なるリージョンへも同一のresourceを構築していくことになります。 main.tf (sample) provider "aws" { region = "ap-northeast-1" }module "network" { source = "./network" cidr = "10.200.0.0/

This is our goal architecture design, please read the article to understand the journey :)This blog article is participating in the Mercari Bold Challenge month (#6) Hi everyone, this is Raphael from the Microservices Platform team at Mercari. Bluntly introduced, we are a post-IPO Japanese C2C (Customer to Customer) marketplace transitioning from a monolithic to a microservices architecture. A few

This is the 3rd blog post for Mercari’s bold challenge month. At Mercari, while migrating our monolithic backend to microservices architecture, we felt the need to have a service mesh and understood its importance in the long run. Most of the incident post-mortem reports had actionable items such as — implement rate-limit, implement a better canary release flow, better network policies… and this i