3/9(木) Google Cloud 主催 Innovators Live Japan に市川が登壇します！ - KAYAC Engineers' Blog
SREチーム（新卒）の市川恭佑です。 Google Cloud が主催するオンライン形式のイベント Innovators Live Japan につきまして、この度、3月9日（木）開催のウェビナー「実録！SRE」の1コーナーを担当することになりました。 cloudonair.withgoogle.com 最年少なのに何故かトリですが、たぶん特別な理由はないので、リラックスして当日を迎えたいと思っています。 発表概要 タイトルは「SRE の目的に立ち返った Infrastructure as Code の再考察」というものです。 イベントの紹介ページには書かれていない背景の補足も含めて、発表内容を軽く紹介いたします。 なぜ Infrastructure as Code の話？ SRE 文脈で Infrastructure as Code（IaC）と聞くと「あくまでもツールの話だよね」という印
【解説編】CircleCIからOIDCを用いて安全にGoogle Cloudにアクセスする - KAYAC Engineers' Blog
SREチーム(新卒)の市川恭佑です。これはカヤックSRE連載の2月号です。 よく見ると投稿日が3月になっていますが、どちらかと言うと2月が28日までしかない方に問題があるので、大丈夫です。(何が？) ということで、2023年も滑り出し好調のカヤックSRE連載ですが、前回の記事ではCircleCIからGoogle CloudにOIDCでアクセスする方法について、 ちゃんと動く(はずの)ソースコードをサクッと紹介いたしました。 techblog.kayac.com さて、Google CloudとCircleCIをお使いの皆様、もうOIDC対応は完了しましたか？ 安心してください。私のプロジェクトでも一部未完遂です。(おい) ということで今回は、前回紹介したソースコードを深掘りして解説します。 私と同じように、途中でなんか面倒になって一旦塩漬けにしたら正直忘れかけてる長い道のりの途中にいる皆様
【実践編】CircleCIからOIDCを用いて安全にGoogle Cloudにアクセスする - KAYAC Engineers' Blog
SREチーム(新卒)の市川恭佑です。これはカヤックSRE連載の1月号です。 みなさんの記憶に新しいと思いますが、先日CircleCIで大きなセキュリティインシデントがありました1。 このインシデントを受けて、環境変数やContextに保存された外部サービスへの認証情報を更新しながら「自分もOIDC対応しておけば......」と後悔した方も少なくないと思います。 外部サービスの例として、Amazon Web Services (AWS)に関しては、公式OrbにてOIDC連携がサポートされていたり、AWS側のIdentity and Access Management (IAM)設定を含む情報がインターネット上に数多く公開されています。 ゆえに、CircleCIのパイプラインからAWSにアクセスする箇所について、OIDC連携に対応する難易度は比較的低いです。 これに対して、Google Clo
GoとテストとSDKとGCP - KAYAC engineers' blog
SREチーム(新卒)の市川恭佑です。これはKAYAC Advent Calendar 2022の9日目の記事です。 今年の弊社アドベントカレンダーは、筋肉やランニング、さらにはサウナなど、多様性に富んだ面白いエントリが出揃っています。 自分も好きなファッションについて書きたくなってしまったのですが、ここはグッと気持ちを抑えて、仕事で触った技術について書きます。 ※ この記事のタイトルは、酒とゲームとインフラとGCPというイベントのオマージュです。 仕事の近況報告 まず、最近どんな仕事をしているのかについて報告させてください。恐らく誰も興味がないと思いますが、年末のアドベントカレンダー企画ということもあるので...... Amazon Web Services(AWS)を用いた自社サービス 今年の4月に新卒入社してから、技術ブログを2本執筆しました。下記がそのリンクです。 techblog.
注意！GCPのUptime Checksの利用料金が1ヶ月で100万円増えてた話 - Qiita
tl;dr 先日GCPの料金レポートを見たら、それまで無料だったUptime Checks(死活監視サービス)の利用料金がなんと100万円を超えていて面食らった。 GCPの一部サービスが、22年10月から料金改定を行うことはニュースや公式のアナウンスでかなり事前に知っていたが、GCSやネットワーク周りのみの認識だった。 しかし実際、それまで完全無料のぶっ壊れサービスだったUptime Checksもしれっと10月から1リクエストにつき0.0003ドル(無料枠あり)の課金がなされるようになっていた。 円安時代、クラウドインフラの利用料金は開発者を悩ます大きな種の一つである。個人、公式のブログなど、料金改定をアナウンスする様々な記事をあたったが、この事実を事前にアナウンスしている記事を見つけることができなかった(要検証)ため、今後どうすればこのような事態を回避できるか検証した。（情報求む！）
Google Cloud Platform Japan 公式ブログ: Secure LDAP を正式リリース ―― LDAP アプリへのアクセスが Cloud Identity で管理可能に
※この投稿は米国時間 2018 年 11 月 27 日に Google Cloud blog に投稿されたものの抄訳です。 私たちはこのほど、10 月の Google Cloud Next '18 in London で発表した Secure LDAP 機能を正式リリースしました。この機能を使用すれば、従来の LDAP ベースのアプリケーションや IT インフラストラクチャへのアクセスを G Suite か Cloud Identity で管理できます。Cloud Identity は Google Cloud のマネージド IAM（Identity and Access Management）プラットフォームです。 SaaS と LDAP アプリの管理を統一 SaaS（Software as a Service）アプリケーションの人気は上昇の一途をたどっていますが、いまだに多くの組織がレ
GCPのネットワークでハマった話
第16回elasticsearch勉強会 https://elasticsearch.doorkeeper.jp/events/46539
Google Compute Engine、全世界のリージョンが同時に外部とのネットワーク接続を失うという深刻な障害が発生。ネットワーク管理ソフトウェアにバグ
Google Compute Engine、全世界のリージョンが同時に外部とのネットワーク接続を失うという深刻な障害が発生。ネットワーク管理ソフトウェアにバグ クラウドのどこかで障害や災害が発生したとしても、その影響はアベイラビリティゾーンを超えることはなく、そのために複数のアベイラビリティゾーン（Google Compute Engineでは「ゾーン」）にシステムを分散して配置することで、クラウドの障害の影響を受けない高い可用性を備えたシステム構築ができる。これはクラウド（IaaS）に対応したシステム構築におけるもっとも基本的な考え方です。 しかし先週、2016年4月11日にGoogle Compute Engineで発生した通信障害は、アベイラビリティゾーンどころかリージョンの境界も越え、世界中にあるすべてのリージョンのインスタンスが同時に外部とのネットワーク接続を18分間に渡って失う
GCPのCentOSでtcp_tw_recycleが有効になっていてハマった - post <$> shiroyama <*> blog
Google Cloud Platform（以下GCP）を評価中であるが、Google Compute Engine（以下GCE）でCentOS 6をイメージとして選択してインスタンスを起動してSocket.IO環境を構築したところ、AndroidとGCE間で 時々 原因不明のSSLハンドシェイク失敗に悩まされ非常にハマった。 結論から言うと、当該インスタンスでは net.ipv4.tcp_tw_recycle が有効になっていた。これを無効にすることで問題は解決した。 1 2 3 4 5 6 % sysctl net.ipv4.tcp_tw_recycle net.ipv4.tcp_tw_recycle = 1 % sudo sysctl -w net.ipv4.tcp_tw_recycle = 0 % sysctl net.ipv4.tcp_tw_recycle net.ipv4.tc
MySQL5.7 / RDS / Aurora / Cloud SQL の性能比較 | 外道父の匠
CloudSQLの価格は実戦的という意味で、per Dayの価格を24hourで割った価格にしています。 メモリは2GBあれば検証としては十分なので格差は関係ありません。 IOPSはEBSならGeneral Purposeの1000GB*3で最大確保しています。 その他、ネットワーク周りなどポイントがあれば都度、補足していきます。 ベンチマークのデータ 今回、採取した全データはこちらになります。一部、目的に対して不要と判断したら省略しています。まぁ、こんなオレオレメモデータを見ても楽しくないでしょうから、１つ１つ考察していきましょう。 手法について 私がよくやる計測方法なのですが、innodb_buffer_pool_size がデータ容量より大きい健全な状態と、最小の16MBで過負荷ストレージを演出し、それぞれで参照／更新を別々にランダムアクセスをすることで、最初のボトルネックを炙り出し
Google、FluentdをKubernetesとCompute Engineの標準ログコレクタに採用 - Qiita
Google、FluentdをKubernetesとCompute Engineの標準ログコレクタに採用FluentdgooglecomputeenginekubernetesGoogleCloud まずはFluentdコミュニティの皆さん、おめでとうございます！！！ Googleを中心に開発されているオープンソースのDockerジョブスケジューラKubernetes (k8s)、それにGoogle Cloud Platformのログ収集サービスGoogle Cloud LoggingのGoogle Compute Engine用ログコレクタとして、Fluentdが標準採用されました。もうひとつおまけに、fluent-plugin-bigqueryをフィーチャしたソリューションページも、あと1か月くらいでcloud.google.comにて公開される見込みです（これは私がいま仕上げ中）。
Google Compute Engineのロードバランサを読み解く#1 #gcpja
ども、takiponeです。 GCE(Google Compute Engine)でVMインスタンスと並んで注目される機能が、ロードバランサ(負荷分散)だと思います。今回から数回に渡ってロードバランサを触り、その特徴をまとめてみたいと思います。 GCEロードバランサの基本 GCEのロードバランサは、2つの独立したサービスがあります。 Network load balancing (L4ロードバランサ) HTTP load balancing (L7ロードバランサ)[Limited Preview] 参考 : Google佐藤さんのQiitaでの紹介 今回は、L4ロードバランサを提供するNetwork Load Balancingを試してみます。 VMインスタンスの準備 まずは、実際に作成して動作を確認します。今回はこちらのエントリーでご紹介した自動構成を利用し、ロードバランサの転送先として
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GCP を支えるロードバランサの設計を公開