こんにちは。スクエニのイギリス支社、ロンドンオフィスで働くヨシダタツオです。アナリティクス&インサイト部署のデータサイエンス部を担当しています。データとAIでスクエニのファンとゲームの関係性を深めるしくみを作っています。スクエニ欧州拠点ではGoogle Cloudを活用してカスタマーデータプラットフォーム(CDP)の開発・運用を行っています。先日、この取り組みについてGoogle Cloud主催のGoogle Cloud Next London 2023にて発表しました。今回は、そこでの発表内容を日本語でも共有するために、このITエンジニアブログに寄稿することにしました。カスタマーデータプラットフォーム(CDP)とは CDPはビジネス全体のデータを収集し活用していくシステムです。一般的には、お客様一人ひとりのデータを収集し、管理し、分析するだけでなく、マーケティングやプロモーションに活用します。スクエニ欧州拠点のCDP開発の経緯 ロンドンのアナリティクス&インサイト部署は、2009年にスクエニに買収されたアイドスというゲーム開発会社のデータ分析チームのルーツを持ちます。アイドスは2007年にゲームプレイデータの収集、分析、機械学習の適用をゲーム業界においていち早く導入し、スクエニに統合後もその活動を継続しています。2007年当時、データ分析基盤としてMicrosoft SQL Serverを利用していましたが、2013年頃にゲームのオンライン化に伴うデータ量の増加に伴いPlutoというAWSベースの内製システムに移行しました。CDP開発の直接のきっかけの一つは2018年に導入された新しいプライバシー法(GDPR)でした。それ以前に主流であったマーケティング手法は、ユーザーデータを提供する会社やそれを活用するデータ連動型の既成ソリューション(例えば、Data Management Platformなど)に依存していました。しかし、GDPRの導入によりこれらの手法が制限され、自社でデータを集める必要性に直面しました。その結果、既存のゲームデータ分析システムであるPlutoを置き換える形で、Google CloudをベースとしたSingle Gamer View(SGV)というシステムが開発され、マーケティングデータ、ユーザーデータ、ゲームデータが一元化されました。CDP

こんにちは、ホシイです。近年、“オンプレ回帰” という言葉がよく聞かれるようになりました。人々 (とシステム) は、クラウドからオンプレに帰ってきているのでしょうか?オンプレ回帰という話題において、場合によって話題の中心が必ずしも合致していないこともあるように感じています。大きくは、実際にクラウドからオンプレに移行を実施する・した人の観点と、それを大きな現象として観察している人の観点の差でもあるように思います。今日は、これをじぶんの考えとしてまとめるべく書き出してみます。(見聞きした情報の影響が多分に含まれます。いくつか末尾に参考にさせていただいた情報への参照を置いておきます)“オンプレ回帰” は増加している まずここで言うオンプレについて、自前で管理するインフラのことを指しているとします。会社のフロアやサーバールーム、借用して専有管理するデータセンターの一角なども含まれるでしょう。そのオンプレへ “回帰” ということですから、オンプレに帰ってきているということです。帰ってきた (くる) ということは、その前にどこかに行っていた (いる) ということです。その多くは、クラウド、より正確にはパブリッククラウドからの回帰でしょう。現在のパブリッククラウド市場は年々成長し、利用者・利用量はまだまだ増加している途上です。数年も逆上ると、パブリッククラウドに行くシステムも今ほど多くはありませんでしたし、戻るにしてもまだ判断が早すぎるタイミングでした。必然的に、クラウド移行が進行してある程度期間がたった今だからこそ回帰の数もまた増えているという見方もできるでしょう。それが目立って、オンプレ回帰が過剰に・想像以上に増加しているととらえられている面もあるのではないでしょうか。ここで言うクラウドとは? さてここで、回帰の元である、クラウドについて考えてみましょう。それらの多くは、上に書いたようにパブリッククラウドだったと思われます。要するに、AWS や Google Cloud、Azure などです。他にもたくさんあります。それとは別に、プライベートクラウドという区分もあります。これはパブリッククラウド同様に他所で間借りをするものもありますが、オンプレ (に区分される設備) に構築する場合も多く、区分的にはオンプレ側 (もしくはそのもの) と考えるべきでしょう。ところで、最近はクラウ

※本記事の画像は「 https://logmi.jp/tech/articles/327868 」から引用しています。睡眠不足のdskです。いきなりですが、クラウドプロバイダーと聞いて思い浮かぶのって AWS , Azure , GCP が多いと思います。わたしもそうです。いまはおもいっきり GCP に携わることが多いので、まっさきに viva GCP! と答えてしまうと思います。そんな中、egressがめちゃくちゃ安い！ が謳い文句(他にもいいとこあるけど)の Linode を使ってみました！Linode とは Linode はAkamai社が提供する IaaS プラットフォームプロバイダサービスです。「リノード」と読みます。なぜ名称に「IaaS」がわざわざ付いてるのかというと、マネージドサービスが「現在はほとんどない」んですよね。なので、「Linode だけでフロントエンドからバックエンドまで構成する」のはちょっと時期尚早感は否めません。じゃあどういうユースケースがあるのかというと、 (ちょっとした)データ加工と分析 他企業や他チームとのコラボレーション時のワークロード実行環境 負荷試験実行環境 脆弱性診断やセキュリティテスト実施環境 と言った、ロケーションを問わない小規模環境から使ってみるのがいいとおもいます。メリット まず浮かぶのはコストが安いってことですね。 と言っても ↑ に記載した通り、小規模環境での利用がいいと思っているので、そもそもコストそんなにかかってなさそうやん！という声が聞こえてきそうです。わたしも Linode が使えそうかという観点でミニマム環境で使ってみたので、コストが安いという実感はまだ得られていません。 よくある「共有/専有CPU」の選択をし、次に「プラン(マシンタイプ)」の選択をするわけですが、プランの中にストレージ(SSD)と転送(egress)が含まれてるんです。 主要クラウドプロバイダーとの価格比較ですが、「4vCPU/8GB」プランにもともと付帯されているストレージと転送量を加味したコストシミュレーションです。細かい部分は置いておいて、これだけ見ると確かにコストメリットを感じることができますね！ちなみに今回ベンチマークは取っていません。「どのくらいの性能出るの？」と気になるひともいるとおもうので、その辺は次回にでも。デメリ

こんにちは! 半年ぶりの執筆となります。nose です。 昨年、とあるゲームタイトルで Web ブラウザ上でプレイできる クラウド体験版 をリリースしました。今回はそのクラウド体験版リリースに纏わる話をしていきたいと思います。本記事の内容 概要 システム構成 バーチャルパッドについて クラウド体験版をリリースした結果 まとめ ※「バーチャルパッドについて」は オバカム が執筆しています。1 概要 今回ストリーミングで出したゲームは STAR OCEAN THE SECOND STORY R です。より広く遊んでもらうきっかけづくりとして Web ブラウザでもプレイできるよう他プラットフォームと同時にクラウド体験版を 2023年9月15日 にリリースしました。こちらのクラウド体験版は 2024年3月 にクローズし現在は遊ぶことができません。 システム構成 システム構成としては二つの枠組みに分けられます。 web サイト ゲームストリーミングサービス 1 の部分では主に S3 と CloudFront を使っており、 2 の部分では Ubitus の GameCloud サービスを利用しています。 参考:Ubitusはスクウェア・エニックス『STAR OCEAN THE SECOND STORY R』体験版のクラウド配信をサポート 1 に来たユーザからのアクセスを 2 のストリーミングサービスに受け渡すといった割とシンプルな作りになっています。今回はクラウド体験版ということもありユーザの識別などもしておらずセーブも出来ない作りにしています。構成図としては以下のようになります。

yotaです。 私のチームではCI/CDツールConcourse上でMavenを使ったJavaプロジェクトのビルド環境を構築中です。 この記事はこちらの記事で言及した、 実は後にConnection timed outの根本的な原因が判明したのですが、それは別途投稿します。 にあたるものです。今回の問題は、MavenによるJavaプロジェクトのビルドが時折Connection timed outでエラーになることでした。以下のようなエラーですが、対象となるプラグイン、ライブラリは常に同じというわけではありませんでした。[ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M8:test (default-test) on project <プロジェクト名>: Execution default-test of goal org.apache.maven. plugins:maven-surefire-plugin:3.0.0-M8:test failed: Plugin org.apache.maven. plugins:maven-surefire-plugin:3.0.0-M8 or one of its dependencies could not be resolved: Failed to collect dependencies at org.apache.maven.plugins:maven-surefire-plugin:jar:3.0.0-M8 -> org.apache.maven. surefire:maven-surefire-common:jar:3.0.0-M8: Failed to read artifact descriptor for org.apache.maven. surefire:maven-surefire-common:jar:3.0.0-M8: Could not transfer artifact org.apache.maven. surefire:maven-surefire-common:pom:3.0.0-M8 from/to (https://<社内ミラーリポジトリ>): transfer f

はじめに この記事を見つけたけど、後で見ようと思ったそこのあなた！ぜひ下のボタンから、ハッシュタグ #ハマグリ式 でポストしておきましょう！ こんにちハマグリ。貝藤らんまだぞ。 今回は、ハマグリ式！ 運用しやすい GitHub と Terraform Cloud の設定例 ～Terraform コード付き～ をお届けします！ 番外編って？ ハマグリ式では、下記のようにレベルを設定しています。 初級者：初めてクラウドサービスを利用する人で、基本的な操作（例：ファイルの保存や、サーバーの起動）をインターフェースを通じて行うことができます。また、シンプルなセキュリティルールの設定や、一部の問題のトラブルシューティングに対応できます。 中級者：より深い知識を持ち、コードを用いて操作を自動化したり、より複雑なタスク（例：自動でサーバーの数を増減させる）を行います。また、より高度な監視や、全体のシステム設計と実装について理解があります。 上級者：幅広く深い知識を持ち、大規模で複雑なシステムを設計、実装、維持する能力があります。最先端のテクノロジーを活用し、安全性、耐障害性、効率性を最大化するためのソリューションを提供します。 今回は上記と関係の薄い GitHub、Terraform Cloud についての記事であるため、番外編に分類しています。ハマグリ式って？ 貝藤らんまが作成するブログ記事のブランド名です。あまり気にせず読み飛ばしてください。何を書くの？ 以下の通りです。 この記事で書くこと Terraform Cloud 連携のための運用しやすい Terraform HCL 基本コード Terraform Cloud 連携のための運用しやすい GitHub 基本設定 Terraform Cloud の運用しやすい基本設定 それらを実現する HCL コード この記事で書かないこと GitHub と Terraform Cloud の OAuth app 連携 Terraform HCL コードの応用、解説、正しいベストプラクティス GitHub 設定の応用、解説、正しいベストプラクティス Terraform Cloud 設定の応用、解説、正しいベストプラクティス 免責事項 この記事に書かれていることは弊社の意見を代表するものではありません。 この記事に書かれていることには一定

yotaです。 私のチームではCI/CDツールConcourse上でMavenを使ったJavaプロジェクトのビルド環境を構築中です。 （Concourseについては本ブログの別記事を参照ください）その中で、Mavenによる依存ライブラリや各種プラグインのダウンロードがConnection timed outとなり、ビルド全体がエラーになるという事象が発生するようになりました。以下のようなエラーですが、対象となるライブラリ、プラグインは常に同じというわけではありませんでした。[ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M8:test (default-test) on project <プロジェクト名>: Execution default-test of goal org.apache.maven. plugins:maven-surefire-plugin:3.0.0-M8:test failed: Plugin org.apache.maven. plugins:maven-surefire-plugin:3.0.0-M8 or one of its dependencies could not be resolved: Failed to collect dependencies at org.apache.maven.plugins:maven-surefire-plugin:jar:3.0.0-M8 -> org.apache.maven. surefire:maven-surefire-common:jar:3.0.0-M8: Failed to read artifact descriptor for org.apache.maven. surefire:maven-surefire-common:jar:3.0.0-M8: Could not transfer artifact org.apache.maven. surefire:maven-surefire-common:pom:3.0.0-M8 from/to (https://<社内ミラーリポジトリ>): transfer failed for https://<社内ミラ

みなさん、こんにちは！初投稿の hamachan です。私は、クラウドの技術で、一例として 急増するユーザアクセスも良い感じで捌く(CM等のプロモーション打つよ～ → どのくらいサーバ増強しておきましょうか？…みたいな議論から不毛だと思ってます。そんな見積もり、とても難しいですよね？) 各種メンテナンスも不要(セキュリティパッチ適用から、バージョンアップ対応などなど面倒くさいのです。) といった、「何もしなくて良い状態」に極力したい人、憧れる人です！さてさて、今や弊社の複数のオンラインゲームタイトルで、GCPのCloud Runが採用されていますが、今回はそれを初めて導入したときのお話です。背景など とあるオンラインゲームタイトルで、国産クラウドから、GCPへ移設するお仕事がありました。この際、ユーザ様からのアクセスを受けるフロント部分に関し、別プロダクト(流行りもあってGKE)にしようという流れがあったのですが、結果Cloud Runにしました。これが初めての導入でした。Cloud Runは冒頭自己紹介部分にも書いた 急増するユーザアクセスも良い感じで捌く 各種メンテナンスも不要 を叶えてくれる可能性があり、私の推しプロダクトでした。この初導入を実現させたく、ずっとこのCloud Runを触っていた時期があります。プロデューサー, 開発担当, チームメンバらにその良さを説明し、共感してもらい、初導入を実現するには自分で手を動かさないとですよね。そんなこんなで今回は、 推しプロダクト(今回だとCloud Run)があって、本番環境に導入してみたい その推しプロダクトの良さを関連メンバに伝えたい 開発担当など、自分以外の人が指定したプロダクトを言われたとおり準備するのではなく、一石を投じたい みたいなことを考えている人には刺さるかもしれない内容となっています。 なお、本記事では、TCO（Total Cost of Ownership）の試算や、Cloud Runの説明、構築/導入手順といったものは割愛させていただきます。 ただ、移設前の国産クラウドで稼働していたことあり、アクセス規模とか正確に分かったので、費用見積もりはやり易かったですね。本題「推しプロダクト(Cloud Run)を関連メンバに伝える手順」 以下のステップで、関連メンバ(プロデューサー,開発担当,チー

こんにちは、疑り深いホシイです。複数の機能を組み合わせてシステムを構築するとき、それぞれの機能同士の通信は必要だがその他の通信は禁止したいということはよくあります。たとえば… 開発中のプログラムで、想定している以外の通信が無いことを確認したい 公開されているソフトウェア (OSS や container image 等) をちょっと試してみたいが、その素性が完全には確認できていないので、外部との通信を遮断した環境で実行してみたい 特に後者のような用途では、実行環境ごと隔離できると何かと便利です。今回は Docker を使ってやってみたいと思います。Docker の実行 option を使用する docker run するときに、--net=none をつけるだけで、container は network から隔離されます。参考: None network driver❯ docker run -it --rm --entrypoint=ash --net=none alpine / # ip link show 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: tunl0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN qlen 1000 link/ipip 0.

はじめに この記事を見つけたけど、後で見ようと思ったそこのあなた！ぜひ下のボタンから、ハッシュタグ #ハマグリ式 でポストしておきましょう！ こんにちハマグリ。貝藤らんまだぞ。 今回は、ハマグリ式！ Jira issue 作成君を Python で書いてみた をお届けします！ 初級って？ ハマグリ式では、下記のようにレベルを設定しています。 初級者：初めてクラウドサービスを利用する人で、基本的な操作（例：ファイルの保存や、サーバーの起動）をインターフェースを通じて行うことができます。また、シンプルなセキュリティルールの設定や、一部の問題のトラブルシューティングに対応できます。 中級者：より深い知識を持ち、コードを用いて操作を自動化したり、より複雑なタスク（例：自動でサーバーの数を増減させる）を行います。また、より高度な監視や、全体のシステム設計と実装について理解があります。 上級者：幅広く深い知識を持ち、大規模で複雑なシステムを設計、実装、維持する能力があります。最先端のテクノロジーを活用し、安全性、耐障害性、効率性を最大化するためのソリューションを提供します。 今回は上記と関係の薄い生成系 AI についての記事であるため、番外編に分類しています。ハマグリ式って？ 貝藤らんまが作成するブログ記事のブランド名です。あまり気にせず読み飛ばしてください。何を書くの？ 以下の通りです。 この記事で書くこと GPT-4 API を使った Jira issue を作成するプログラム プログラムの拡張案 この記事で書かないこと GPT-4 の解説 python コードの解説 AI やプログラムの精度の検討 プログラムの拡張案の比較検討 免責事項 この記事に書かれていることは弊社の意見を代表するものではありません。 この記事に書かれていることには一定の調査と検証を実施しておりますが、間違いが存在しうることはご承知おき下さい。 筆者の専門外の内容については断定を避けておりますが、あらかじめ間違いが存在しうることはご承知おきください。 記事の内容は、記事執筆時点 (2024/1) での情報です。ご承知おきください。 GPT-4 API を使った Jira issue 作成君を Python で書いてみる 巷で話題の GPT-4 、せっかくなら業務に組み込みたいですよね。

みなさん、こんにちわ！初投稿のドリアです。2011年にAWSの東京リージョン、2016年にGCPの東京リージョンが開設されてから クラウド環境を利用する機会も増えたのではないでしょうか。 柔軟なインフラリソースの活用に加えて様々なマネージドソリューションが発表される中で クラウドのセキュリティはどうしているの？と気になる方もいると思いますので 本日はクラウドのセキュリティ製品を触ってみたことについて書いてみようと思います。クラウドのセキュリティといってもどういったものがあるの？ クラウドセキュリティといっても各クラウドが提供している製品や3rdベンダーが提供している製品、防御範囲も多種多様にあるかと思います。今回はクラウドプラットフォームが提供しているGCPのSCC(Security Command Center)についてポストしようと思います。※AWSの類似製品はGuard Dutyというものがあります。SCCってなーに？ Google Cloud Platform向けのセキュリティとリスク管理製品です。Security Command Center検知項目は300超あり、不正なDNSへのアクセスやFWの脆弱性情報、アカウントの異常利用など様々なセキュリティ情報を検知してくれます。有効化してみた なんとなく製品は聞いたことある、なんとなく知ってるけど、、、って人も多いと思うので特定のorg配下で、試しに有効化した際の画面を貼っています。 桁数は伏せますが、大量に検知されることが分かりました。それもそのはずで、GoogleがGCPプロジェクト作成時にデフォルトで作ってくれるDefalutのネットワークやDefaultのFirewallなど利用していなくてもSCCが検知してくれるケースも多数ありました。※組織ポリシーでdefault類の作成を抑止している場合、その限りではない。この数を検知し続けると運用が成り立たない 色々と検知してくれるのは良いことではありますがGoogleのセキュリティ基準と自分たちのセキュリティ基準は各社異なると思いますので自分たちが検知したいルールを定めて、各パラメータごとにレベル分けをすることをお勧めします。参考までに我々がSCCの検出結果をどういったプロダクトでフィルタリングや検知をしているか、構成を載せておきます。 SCCではいくつかの機

こんにちは、ホシイです。機械学習が業務に入り込んで、GPU つきの PC やサーバーを共有機として使用することが増えました。以前から自動テスト等の用途で需要はあったかと思いますが、急速に進んでいるように感じます。今日は、こうやって増えてきたホストの GPU のみなさんが、元気よく働いている様子を確認しやすくする仕組みを用意してみたいと思います。Observability に関しては以前、JMX MBean metrics の可視化を試す を書きました。また、Cloud Monitoring で custom metrics を活用する という記事で、CLI output を parse して custom metrics 化についても書いています。今回もこのあたりの仕組みを使い、custom metrics をつくればできそうだな… と思っていました。nvidia-smi も、よく見る人間に読みやすい形式だけではなく monitoring ぽい出力にも対応しているようですし。しかし！web 検索していると、やはりみんなホシイと思っているものはすでにつくられているものです。今回はそちらをありがたく利用させていただくことにしましょう。NVIDIA DCGM Exporter を使用して GPU の monitoring をしてみるサンプル NVIDIA 社が DCGM Exporter という、Prometheus 等に metrics を収集させるためのソフトウェアを提供しています。GitHub 上の repo を確認すると、license は Apache License 2.0 とありました。冒頭にも書きました 以前の記事 の内容も流用し、Docker compose を使って Prometheus + Grafana とともに この exporter を使い、情報の可視化をしてみましょう。

はじめに この記事を見つけたけど、後で見ようと思ったそこのあなた！ぜひ下のボタンから、ハッシュタグ #ハマグリ式 でポストしておきましょう！ こんにちハマグリ。貝藤らんまだぞ。 今回は、ハマグリ式！ AWS Linux ログイン RTA をお届けします！ 初級って？ ハマグリ式では、下記のようにレベルを設定しています。 初級者：初めてクラウドサービスを利用する人で、基本的な操作（例：ファイルの保存や、サーバーの起動）をインターフェースを通じて行うことができます。また、シンプルなセキュリティルールの設定や、一部の問題のトラブルシューティングに対応できます。 中級者：より深い知識を持ち、コードを用いて操作を自動化したり、より複雑なタスク（例：自動でサーバーの数を増減させる）を行います。また、より高度な監視や、全体のシステム設計と実装について理解があります。 上級者：幅広く深い知識を持ち、大規模で複雑なシステムを設計、実装、維持する能力があります。最先端のテクノロジーを活用し、安全性、耐障害性、効率性を最大化するためのソリューションを提供します。 ハマグリ式って？ 貝藤らんまが作成するブログ記事のブランド名です。あまり気にせず読み飛ばしてください。何を書くの？ 以下の通りです。 この記事で書くこと AWS で Linux にログインするための最短手順 この記事で書かないこと AWS VPC のベストプラクティス AWS EC2 のベストプラクティス AWS で Linux にログインするための真の最短手順 免責事項 この記事に書かれていることは弊社の意見を代表するものではありません。 この記事に書かれていることには一定の調査と検証を実施しておりますが、間違いが存在しうることはご承知おき下さい。 筆者の専門外の内容については断定を避けておりますが、あらかじめ間違いが存在しうることはご承知おき下さい。 記事の内容は、記事執筆時点 (2023/12) での情報です。ご承知おき下さい。 Linux ログイン RTA IT インフラで最もスタンダードなリソース、それは Linux であると言ってもよいでしょう。検証してみたいとき、まずは Linux を起動してログインするところから始まります。

こんにちは、ホシイです。貧乏性なので、仕事中はたいてい費用のことを考えています。今回は、機械学習インフラにも関連する記事です。AI に関しては SQUARE ENIX AI 技術ブログ もありますので、ご興味がありましたらぜひご覧ください！GPU をお安く、好きなときに好きなだけ利用したい AI の話題花盛りの昨今、アプリケーションで GPU を利用する機会も増えてきました。GPU の用途もいろいろとありますが、最近でわたし周辺の需要として特に多いのは、機械学習です。ざっくり言うとタスクに対してパラメーターやデータを与えてある程度の時間、計算処理をするものです (なんでもそうと言えばそうですが)。ここでの問題は、GPU は基本的に高価で購入することに敷居があるうえに、それをホストに組み込んでかつ共有リソースとして利用するというのはなかなか難しいというものです。今回の記事ではこれをスマートに解決する例をつくってみたいと思います。GKE Autopilot で。最初は Cloud Run を調べたのですが、通常の Cloud Run では GPU が使えないようでした (GKE node を使えばできそう)。GPU が使える選択肢として考えられる GCE や GKE Standard では、ゼロから scale させる仕組みをつくりたいとなると、追加の工夫が必要そうです。GKE Autopilot では cluster を常時維持する必要はありますが、GPU 含めてリソース管理するシステム費用と考えるとじゅうぶん妥当な費用と感じます。※ Vertex AI を使え… という声が聞こえてきますが、ここでは聞こえないこととします。GCP 以外でもいろいろと便利なサービスはあるぞ！というかたは、どこかでお会いしたときに教えてください 🙏ちなみに今回の記事、かなり類似した内容がこちら → GKE で GPU 使うのめっちゃ簡単 (Google Cloud Uchimaさんの記事) にあるのを観測しております。Autopilot などについてはそちらで詳しく説明されていますので、あわせてご参照ください。想定アプリケーションシナリオ 今回は、以下の仮想要件向けにソリューションをつくってみましょう。エンドユーザーには web UI を提供し、その操作に応じて機械学習の処理を実行する...

はじめに こんにちは、情報システム部 SRE 橋本です。今回はQiitaのNew Relic Advent Calendar 2023の14日めの記事として書きました。担当しているシステムでサービス監視やSLI/SLOを用いて、どのようにしてサービスの健全性を知るのか？というのを考えていく中でNew Relicが課題解決に繋がるかもしれないと思い、直近でチームで評価を行いました。この記事では、どのような課題感を持っていたのかというのと、その課題感に対して当該プロダクトがどう刺さったのかを簡単にお話したいと思います。サービスとその信頼性 BtoBやBtoCなどで違いはあると思いますが、サービスがあり（中央）、サービスの提供者（下）、サービスを利用するお客様などの利用者（上）という3つの関係性で整理できます。 この関係性の中で、我々は利用者が正常にサービスを利用できているかを知りたいという欲求があります。伝統的な監視 そこで自分たちのシステムに対して監視を行うことになります。PrometheusやZabbix、Sensu、Munin、Cacti、Nagios、MRTG、etc…といろんなツールがありますが、メトリクスを取得してグラフ化したりゲージやカウンターの値をもとに監視やパフォーマンス計測をしたりします。また、ログもどこかに集約したり、もしくはサーバに直接入ってエラーが発生したら確認したりします。 しかし、これら伝統的な監視だけで正しくサービス適用が出来ているかを判断することは実は難しいのです。CPU使用率が高ければ、エラーが少し出たらお客様が本当に困るのでしょうか？困っているかもしれないし、困っていないかもしれません。これだけでは分からないのです。夜中にアラートで起こされたエンジニアにとって、「誰も困っていないかもしれないからアラート対応しません」 とは言い切れないのです。 スパイクして落ち着いた形跡が分かるメトリクスのグラフを貼ってログをチャットでシェアして 「静観します」 とだけ書いて再び眠りについた経験があるのではないでしょうか。また、大きな障害が万が一発生した場合、エラーが出ているがどれだけの深刻度合いなのかが即時に判断できず、エスカレーションをどこまで行うべきか迷ったことがあるかもしれません。Site Reliability Engineering そこ

みなさん、こんにちは！そろそろ新卒と名乗るのもおこがましい気がするオバカムです。オバカムがいるチームでは、インフラの管理にTerraform Cloudを使っています。Terraform Cloudから管理対象のリソースへのアクセスには(当然ながら)認証情報が必要になります。昨今、永続的な認証情報はセキュリティリスクとして受け取られるようになってきているため、例えばOIDCを利用して一時認証を使うなど、永続的な認証情報を避ける方法が重要視され始めています。というわけで今回はTerraform CloudとOIDCにまつわる小ネタをいくつか紹介します！ 今回は管理リソースはAWSとGoogle Cloudにあることを前提とします。1OIDCを利用したTerraform Cloudでのリソース管理の概略図は以下を想定します。 以下のような流れで一時的な認証情報を取得します。 Terraform CloudのWorkspaceでPlan/Applyをする際に各クラウドのIAMサービス2にアクセスキーを要求 各クラウドのIAMサービスはTerraform CloudのOpenID ProviderにWorkspaceの情報を問い合わせ OpenID ProviderはWorkspaceの情報をIDトークンとして各クラウドのIAMサービスに提供 各クラウドのIAMサービスは提供されたIDトークンをもとにアクセス権限を設定し、期限付きのアクセスキーを生成し提供 OIDCを利用してTerraform Cloudからリソースに一時認証でアクセス OIDCを介してTerraform Cloudが動的認証情報を得るにはいくつかのステップを踏む必要があります。 各クラウドにTerraform CloudのOIDC Providerを認識してもらう 各クラウドでのアクセス権限設定 Terraform CloudのWorkspaceの環境変数設定 順を追って説明していきます。管理クラウド側に利用するOIDC Providerを設定 まずは管理対象のクラウドに利用するOIDC Providerを認識してもらいましょう。OIDC Providerの認識部分でどちらも抑えておくべきポイントは以下です。 Issuer(OIDC ProviderのURL)を指定 Terraform Cloudではht

はじめに この記事を見つけたけど、後で見ようと思ったそこのあなた！ぜひ下のボタンから、ハッシュタグ #ハマグリ式 でツイートしておきましょう！ こんにちハマグリ。貝藤らんまだぞ。 今回は、ハマグリ式！ VPC 「など」の設定項目をわかりやすくざっくり解説する ～AWS SDK for Python (Boto3) コードもあるよ～ をお届けします！ 初級って？ ハマグリ式では、下記のようにレベルを設定しています。 初級者：初めてクラウドサービスを利用する人で、基本的な操作（例：ファイルの保存や、サーバーの起動）をインターフェースを通じて行うことができます。また、シンプルなセキュリティルールの設定や、一部の問題のトラブルシューティングに対応できます。 中級者：より深い知識を持ち、コードを用いて操作を自動化したり、より複雑なタスク（例：自動でサーバーの数を増減させる）を行います。また、より高度な監視や、全体のシステム設計と実装について理解があります。 上級者：幅広く深い知識を持ち、大規模で複雑なシステムを設計、実装、維持する能力があります。最先端のテクノロジーを活用し、安全性、耐障害性、効率性を最大化するためのソリューションを提供します。 ハマグリ式って？ 貝藤らんまが作成するブログ記事のブランド名です。あまり気にせず読み飛ばしてください。何を書くの？ 以下の通りです。 この記事で書くこと AWS VPC 「など」の基本的な設定項目がどういうものか AWS VPC 「など」の設定項目をとりあえずどうすればいいか AWS VPC を作成する AWS SDK for Python (Boto3) コード この記事で書かないこと AWS VPC 「など」のすべての設定項目がどういうものか AWS VPC 「など」の設定項目の選び方 AWS VPC 「など」の設定項目の応用 AWS VPC 「など」のベストプラクティス AWS VPC 「など」と AWS 他サービスとの連携 Python コードの解説 免責事項 この記事に書かれていることは弊社の意見を代表するものではありません。 この記事に書かれていることには一定の調査と検証を実施しておりますが、間違いが存在しうることはご承知おき下さい。 筆者の専門外の内容については断定を避けておりますが、あらかじめ間違いが存在しうることはご

こんにちは、ホシイです。みなさんは、どのように Kubernetes を活用されていますか。そもそも Windows container とは 以前に、Docker でやってみる Windows container という記事を書きましたが、ここにいらしたあなたはもしかして、ご覧いただけたりしていますでしょうか。ふだん Docker を使って container を利用しているというと、たいていは Linux application の利用ではないでしょうか。実は Windows container も同様に Docker (for Windows) で利用ができます。というのが前回の記事の内容でした。今回は、Kubernetes から Windows container を利用してみましょう。何のために? 応用・用途としては Windows でしか提供されていないソフトウェアを使用して CI job・batch 処理のようなものを実行したい、Windows application の build がしたいなどが考えられます。具体的には Visual Studio であるとか、… いろいろありそうですね。やってみよう GKE + Terraform でやってみます。cluster の部分は特別なことはないので node pool の部分のみ抜粋します。ひとつの cluster に、Linux と Windows の node pool を混在させることができます。設定内容は一通り確認して、service account などの部分は用途・必要に応じて調整してください。

はじめに この記事を見つけたけど、後で見ようと思ったそこのあなた！ぜひ下のボタンから、ハッシュタグ #ハマグリ式 でツイートしておきましょう！ こんにちハマグリ。貝藤らんまだぞ。 今回は、ハマグリ式！ EC2 の設定項目をわかりやすくざっくり解説する ～AWS SDK for Python (Boto3) コードもあるよ～ をお届けします！ 初級って？ ハマグリ式では、下記のようにレベルを設定しています。 初級者：初めてクラウドサービスを利用する人で、基本的な操作（例：ファイルの保存や、サーバーの起動）をインターフェースを通じて行うことができます。また、シンプルなセキュリティルールの設定や、一部の問題のトラブルシューティングに対応できます。 中級者：より深い知識を持ち、コードを用いて操作を自動化したり、より複雑なタスク（例：自動でサーバーの数を増減させる）を行います。また、より高度な監視や、全体のシステム設計と実装について理解があります。 上級者：幅広く深い知識を持ち、大規模で複雑なシステムを設計、実装、維持する能力があります。最先端のテクノロジーを活用し、安全性、耐障害性、効率性を最大化するためのソリューションを提供します。 ハマグリ式って？ 貝藤らんまが作成するブログ記事のブランド名です。あまり気にせず読み飛ばしてください。何を書くの？ 以下の通りです。 この記事で書くこと AWS EC2 の基本的な設定項目がどういうものか AWS EC2 を作成する AWS SDK for Python (Boto3) コード この記事で書かないこと AWS EC2 のすべての設定項目がどういうものか AWS EC2 設定項目の選び方 AWS EC2 設定項目の応用 AWS EC2 と AWS 他サービスとの連携 python コードの解説 免責事項 この記事に書かれていることは弊社の意見を代表するものではありません。 この記事に書かれていることには一定の調査と検証を実施しておりますが、間違いが存在しうることはご承知おき下さい。 筆者の専門外の内容については断定を避けておりますが、あらかじめ間違いが存在しうることはご承知おきください。 記事の内容は、記事執筆時点 (2023/10) での情報です。ご承知おきください。 AWS EC2 の設定項目をざっくり解説する AWS で最

はじめに こんにちは、クラウドエンジニアの査です。最近はGCP関連のインフラ、特にGKEやKafkaの構築、メンテナンスと監視周りの業務を担当しています。本日は、以下の構成図のように、Kafkaから収集したメトリクスを利用して、KubernetesのHPAを制御し、アプリケーションのパフォーマンスを自動的に調整する方法を解説したいと思います。 Kubernetesを使用してコンテナ化されたアプリケーションをデプロイする際、アプリケーションの負荷やトラフィックの変動に柔軟に対応できることが重要です。そのために、Kubernetesクラスター内のアプリケーションを自動的にスケーリングできるHorizontal Pod Autoscaler（HPA）というKubernetesの強力な機能があります。Kafkaは、分散メッセージングシステムとしての優れた性能と信頼性を提供する一方、トラフィックの変動に適応できるスケーリングメカニズムが求められます。利用した技術の一覧 Kafka_exporter kafkaクラスターのメトリクスを収集するためのexporterCustom-prometheus GKE用prometheusエンジン、デプロイされたexporterからメトリクスを定期的に取得し、Monarchに保存することが可能Monarch Monarch は、すべての Prometheus データを 24 か月間、追加費用なしで保存するデータベースStackdriver-adapter カスタム指標をHPAに利用させられるようにするアダプターHPA 管理対象となるPodの数を、指定したメトリクス（例えばCPU使用率）に基づいて自動的にスケールさせる実装例と注意点 Kafka_exporter SystemサービスとしてKafkaクラスターに実装されます。注意点 GKEのPodのcidrからのTCPアクセスをFirewallで許可する必要があります(デフォルトのポート: 9308)。 Custom-prometheus gkeでprometheus-engineを実装し、prometheusのscrape_configsに下記の例のように設定します。apiVersion:v1kind:ConfigMapmetadata:namespace:gmp-publicname:cu

はじめに この記事を見つけたけど、後で見ようと思ったそこのあなた！ぜひ下のボタンから、ハッシュタグ #ハマグリ式 でツイートしておきましょう！ こんにちハマグリ。貝藤らんまだぞ。 今回は番外編として、ハマグリ式！ 2023年度前半の「生成 AI 関連リンク」約50選をお届けします！ 番外編って？ ハマグリ式では、下記のようにレベルを設定しています。 初級者：初めてクラウドサービスを利用する人で、基本的な操作（例：ファイルの保存や、サーバーの起動）をインターフェースを通じて行うことができます。また、シンプルなセキュリティルールの設定や、一部の問題のトラブルシューティングに対応できます。 中級者：より深い知識を持ち、コードを用いて操作を自動化したり、より複雑なタスク（例：自動でサーバーの数を増減させる）を行います。また、より高度な監視や、全体のシステム設計と実装について理解があります。 上級者：幅広く深い知識を持ち、大規模で複雑なシステムを設計、実装、維持する能力があります。最先端のテクノロジーを活用し、安全性、耐障害性、効率性を最大化するためのソリューションを提供します。 なお上記は ChatGPT による出力ですが、この記事でほかに生成 AI によって出力された文章はありません。今回は上記と関係の薄い生成系 AI についての記事であるため、番外編に分類しています。ハマグリ式って？ 貝藤らんまが作成するブログ記事のブランド名です。あまり気にせず読み飛ばしてください。何を書くの？ 以下の通りです。 この記事で書くこと 2023年度前半の「生成 AI 関連記事」 この記事で書かないこと 生成 AI 各社比較 生成 AI とは何か 生成 AI の活用方法 免責事項 この記事に書かれていることは弊社の意見を代表するものではありません。 この記事に書かれていることには一定の調査と検証を実施しておりますが、間違いが存在しうることはご承知おき下さい。 要約は生成 AI を利用せず、転載にあたらないよう留意しながら人間の手で記述しています。 2023年度前半の「生成 AI 関連リンク」約50選 それでは、貝藤らんまが独断と偏見で選んだ生成 AI 関連リンクを50個くらい紹介するぞ。チェックしていないページが無いか確認しよう！

データベースの変更に対して非同期で処理を追加したい こんにちは、ホシイです。サーバーアプリケーションをつくっていて、あるデータが追加されたり変更されたときに、別の処理を追加したいということがよくあります。アプリケーションの実装を変更してそこに直接処理を追加することも出来ますが、その改修自体が難しかったり、テストの工数がとれなかったり、負荷増大につながる懸念があったりといった問題はよくついてまわるものです。追加の処理が元の処理とおなじトランザクション内にある必要がない・多少遅れても問題ないといった場合は、外部的な非同期処理として追加する手法もよく用いられます。たとえば、ユーザーが新規追加された後、ほぼリアルタイム (通常数秒〜 遅れくらいの期待値) でアイテムボックスに歓迎アイテムをプレゼントする、みたいなことに使えます。今回はそんなユースケース向けに、元の処理に手を入れずに streaming (逐次) 型で処理を追加する例を見てみましょう。以前には、シリーズで streaming data 関連の記事 を書いたりもしていますので、よろしければそちらもご覧ください。Spanner database / table の準備をする まずは、Spanner 自体の準備をします。(なるべく安く…) instance と database を作成し、そこに table を作成しておきます。TESTNAME=hoshy-test gcloud spanner instances create ${TESTNAME} \ --description="${TESTNAME}" \ --config=regional-us-central1 --processing-units=100 gcloud spanner databases create db1 --instance=${TESTNAME} gcloud spanner databases ddl update db1 --instance=${TESTNAME} \ --ddl='CREATE TABLE Singers ( SingerId INT64 NOT NULL, FirstName STRING(1024), LastName STRING(1024), SingerInfo BYTES(MAX) ) PR

こんにちは 👋 ホシイです。コロナウィルスによる感染はまだ続いている様子があるものの、自粛措置は落ち着き、対面の大規模な技術関連イベントも多く戻ってきました。今回は、先日 8月3日 に福岡市で開催されました CloudNative Days Fukuoka 2023 に参加してきたレポートと、この機会を活用して福岡にある二社さまのオフィスを訪問させていただくことができましたので、その様子も合わせてお伝えいたします。CloudNative Days Fukuoka 2023 こちらのイベントへの参加ははじめてで、クラウドネイティブの技術動向はもちろん、それが福岡の地域性とどのように合わさったものになるのかといった点に注目していました。イベント会場は便利な場所にありじゅうぶんに広く、当日は暑い日でしたが開場早々から多くの参加者が訪れていました。オンラインでも参加が可能で、広いテーマで様々なセッションがありました。各セッションでは地域性を活かした、現地のコミュニティや会社による発表、参加者の勢いが強く感じられました。セッションの様子は公式サイトから オンライン視聴 も可能なようなので、気になるトピックがあれば見てみてください。キーワードは他の技術カンファレンスでも取り上げられるものに似た様子ではありますが、より具体的な活用例が多く語られていた印象を持ちました。展示ブースや自由に書けるホワイトボードが置かれたスペースもあり、セッションの合間に多くのかたにご挨拶ができました。思っていたより関東圏含め他の地域からの参加も多かったことに驚きましたが、開催地が違うことで、会話の前提が異なるのがおもしろいです。(会場の様子がわかる写真をと思ったのですが、大勢が写っているものが多く省略させていただきます。ごめんなさい！)オフィス訪問 今回は事前に、普段からお世話になっている Google Cloud の企業ユーザー会である Jagu’e’r にて、訪問をお受け入れいただける先があるかお声かけさせていただきました。その結果ありがたく二社さまからお招きをいただき、お伺いすることができました。それぞれについて、お話の内容とともにご紹介させていただきます。ゼロバンク・デザインファクトリー株式会社さま (以下 ZDFさま)銀行というイメージにとらわれないような新しい形態のサービスを展開されてい...

はじめに この記事を見つけたけど、後で見ようと思ったそこのあなた！ぜひ下のボタンから、ハッシュタグ #ハマグリ式 でツイートしておきましょう！ こんにちハマグリ。貝藤らんまだぞ。 今回は番外編として、ハマグリ式！ 生成系 AI で抽象的な課題に挑戦する ～物語プロット生成～ をお届けします！ 番外編って？ ハマグリ式では、下記のようにレベルを設定しています。 初級者：初めてクラウドサービスを利用する人で、基本的な操作（例：ファイルの保存や、サーバーの起動）をインターフェースを通じて行うことができます。また、シンプルなセキュリティルールの設定や、一部の問題のトラブルシューティングに対応できます。 中級者：より深い知識を持ち、コードを用いて操作を自動化したり、より複雑なタスク（例：自動でサーバーの数を増減させる）を行います。また、より高度な監視や、全体のシステム設計と実装について理解があります。 上級者：幅広く深い知識を持ち、大規模で複雑なシステムを設計、実装、維持する能力があります。最先端のテクノロジーを活用し、安全性、耐障害性、効率性を最大化するためのソリューションを提供します。 今回は上記と関係の薄い生成系 AI についての記事であるため、番外編に分類しています。ハマグリ式って？ 貝藤らんまが作成するブログ記事のブランド名です。あまり気にせず読み飛ばしてください。何を書くの？ 以下の通りです。 この記事で書くこと 生成系 AI を抽象的な課題へ適用するアプローチ この記事で書かないこと 生成系 AI で抽象的な課題を完璧に解決する方法 生成 AI とは何かという説明 生成 AI 各社比較 生成 AI の活用方法 免責事項 この記事に書かれていることは弊社の意見を代表するものではありません。 この記事に書かれていることには一定の調査と検証を実施しておりますが、間違いが存在しうることはご承知おき下さい。 筆者の専門外の内容については断定を避けておりますが、あらかじめ間違いが存在しうることはご承知おきください。 生成系 AI による文章を含むため、事実と異なる内容がある可能性があることをご承知おきください。 キャラクターに関するプロンプトは下記の通り、著作権を違反しないような抽象的な文言を使用しております。 ChatGPT Custom Instructions: pr

今回は Observability の例として、ふとしたきっかけで知った JMX MBean metrics を扱ってみます。JMX (Java Management Extensions) というと、Java program の debug や一時的な状態確認のような用途の印象があったのですが、これを用いて metrics を公開する application があるのははじめて知りました。この仕組みを利用することにより、application 特有の指標情報を収集して可観測性を向上できます。検証環境をつくる Docker Compose を使います。末尾に compose.yaml を置いておきますが、以下のような構造にしています。workspace ├─ compose.yaml ├─ jmxexporter.yaml └─ prom-data └─ prometheus.yaml JMX MBean metrics を公開する application として、Kafka を例にとっています。ちょっと大仰ですが、ちゃんと Kafka を cluster で起動しているので yaml (記事末尾) が大きくなっています。また、動作の様子を視覚的に確認できるように Kafka UI も使えるようにしています。JMX Exporter 今回のポイントです。JMX metrics を可視化するにあたり、今回は Prometheus を使ってみました。Prometheus は JMX metrics をそのまま扱うことはできず、その間の橋渡しが必要になるようです。そこで、JMX Exporter を使います。以下のような設定 jmxexporter.

こんにちは ㊗️ ホシイです。当ブログ、ちょっと日が過ぎてしまいましたが、先日一周年を迎えました ㊗️こうしてご訪問いただく皆様のおかげです。これからもよろしくお願いいたします。当ブログの運用 そしてようやくついこのあいだなのですが、ブログ運営に大きな仕組みのアップデートをしました。今更感もありますが、自動 build からの自動での preview 環境への反映をようやく達成したのです。 git commit → push すると、それを trigger としてサイトを build し、確認環境 (preview 環境) への反映までを行います。以前の記事 に一度書いていましたが、これまでは preview 環境への反映も手動でした。当ブログ作成に使用している Hugo では test server の起動もかんたんなので手元でもすぐに確認はできるのですが、手元に環境がない人に記事のレビューを依頼するときなどはやはりすぐに閲覧ができるサイトがあると便利です。この反映が自動になることで、手間の軽減はもちろん、誰が記事を書いても確実に preview site に更新がされることで、レビューの確実性もあがりそうです。以下、この仕組みを順にざっと説明します。CI でやっていること まず、当ブログのソースは、自前で構築した GitLab™1 環境で host しています。記事を書く人それぞれが git clone してソースを手元に置き、作業しています。GitLab には GitLab CI/CD というツールが用意されています。git repo に .gitlab-ci.yml という名前で pipeline 設定を書いておくとその指示に従って処理をしてくれる仕組みです。かんたんに言うとそこに、「Merge Request がある branch に push をされたら build & deploy をしてね」という指示を書いて動作させています。上の図で言うと CI Runner のところです。

はじめに このページは以下の記事シリーズのうち、自律的に構成したVMインスタンスのテストについて説明します。 概要編 VMイメージ継続ビルド編 サーバ自律構築編 テスト編(このページ) テストの位置付け テストと書くと内包される意味は多岐にわたりますが、ここでは構築後のテストを行うということで、特にAnsibleによるプロビジョニングの定義やmetadataを通じて外部から注入された設定値が正しく反映されているかの比較を行うことを目的と定めています。 設定値として注入する値そのものが間違っている…という可能性やtypoなどもテストの範囲に含めたり、正常動作確認をしたい…などテストに様々な要件を載せてしまいたくなるのですが、さまざまな要件を載せてしまうと複雑怪奇な、メンテナンスが困難なものになる可能性があるため、不足気味でも良いのでシンプルなテストを徐々に育てていく方針で実装しています。仮に運用中に不具合や問題が発生した場合は、テストケースの不足であるかどうかを評価し、テストケースの追加によって対処し次回以降は問題発生しないようにするというループを回せるようにしています。人が頑張って気づけることには限界がありますし、問題の再発防止策にチェックを気をつける/ダブルチェックを頑張ると書くのはツライので、あくまでサーバ構築における問題はテストケースの不足であることに帰着させる構造は重要だと考えています。テストツールについて ツールはOSSのgossを使用しています。gossを選んだ理由は以下のようなものになります。 全体的にシンプル Go言語を元にしたツールであるため1つのバイナリファイルで実行可能であり配布性などが良い text/templateのテンプレートエンジンなのでhelm等と共通した知識でメンテナンスできる serverspec alternativeと開発者は呼称していますが、serverspecほど機能豊富というわけではありません。しかし、それが故に記述やできることが限られるためにシンプルなテスト記述を維持できるのではないかと考えています。また、gossはserverspecと違いテスト対象のサーバ上でgossを実行する必要があります。概要編でも掲載した下記の図のフローではテストの際にgossをセットする手間などが発生することになるのですが、自律構築の場合は

はじめに このページは以下の記事シリーズのうち、VMインスタンスを自律的に構築する方法について説明しています。 概要編 VMイメージ継続ビルド編 サーバ自律構築編(このページ) テスト編 GCPでVMインスタンスを自動・自律的に構築する仕組み ここでは概要編でも貼った以下の画像の中で赤枠の部分にフォーカスを当ててご紹介します。ここではMySQLサーバの構築を例にとっています。 自律構築の流れ 自律構築は以下のような流れになっています。SREがTerraformを用いて適切なパラメータを付与してVMインスタンスを起動すると、それらのパラメータに従って運用可能な状態まで人手を介さずに自動的にセットアップが実行されます。 TerraformによりMySQLカスタムイメージを指定してVMインスタンスが起動。この際にVMインスタンスのmetadataに後の自動構成時に使用されるパラメータを併せて定義します。 VMインスタンスの初回起動時にcloud-initが実行される。user-dataを独自に指定することで起動処理をカスタマイズ可能で、user-dataはmetadataを介してサーバに読み込まれます。 user-dataに記述された処理に従って設定データの生成やAnsibleタスクが実行されます。 MySQLベースイメージのビルド 前述1.のMySQLカスタムイメージは事前にPackerによって図のようなビルドが行われるようになっています。VMイメージ継続ビルド編で記載したようにまずは共通ベースイメージがビルドされ、保存された共通ベースイメージから起動したインスタンスを基にしてMySQLの共通のベースイメージがビルドされMySQLベースイメージとして保存されます。 github actions workflowでの呼び出し方は以下のようにmysqlに関わる定義の部分のみが違う形になっています。jobs:build:#省略steps:#省略- name:set base image configurations to GITHUB_ENV- run:. ./script/set_env.sh base+ run:. ./script/set_env.sh mysqlworking-directory:packer- name:Packer build image- run

はじめに このページは以下の記事シリーズのうち、VMイメージの継続ビルドについて説明しています。 概要編 VMイメージ継続ビルド編(このページ) サーバ自律構築編 テスト編 VMイメージ継続ビルド 運用しているシステム向けのVMイメージの継続ビルドにはPackerを用いています。ビルドの仕組みの概観は以下のようになります。 Github Enterprise Server(GHE)のActionsを起点として動作する CIサーバ(Actions self-hosted runner)がPackerのビルド・ジョブを実行 Packerにより起動されたサーバに対してAnsibleによるプロビジョニングが実行される プロビジョニング済のサーバを停止・削除しながらカスタムイメージとして保存する ファイル構成 この仕組みのファイル構成は以下のようなツリー構造になっています。AnsibleはPackerからだけ呼び出されるわけではありませんので、それぞれ独立したディレクトリに配置しています。# project root . ├── packer │ ├── config │ │ └── build_env.yaml │ ├── script │ │ └── set_env.sh │ └── source │ ├── base.pkr.hcl │ └── mysql.pkr.hcl │ └── redis.pkr.hcl │ └── memcached.pkr.hcl ├── ansible │ ├── ansible.cfg │ ├── base.yml │ ├── group_vars │ │ ├── base.

はじめに こんにちは、情報システム部 SRE 橋本です。今回は我々のチームで運用効率化として構成しているVMインスタンスの自動的・自律的な構築を行う仕組みについて紹介したいと思います。昨今、クラウド・プラットフォーム上で様々なマネージド・サービスが利用可能になっていますが、10年スパンで継続運用されているシステムでは移行難易度的にそれらのサービスを使うことが難しく、従来構成を維持してVMインスタンスを大量に構築する機会があります。我々の運用システムでもフロントエンドはGKE/コンテナ化が進みつつありますが、DBやKVSなどのデータストアはVMインスタンスで構築しています。またMySQLなどのデータベースサーバではパフォーマンス等の要件により垂直・水平分割がすすんだ結果、構築台数が多くなるというケースはしばしば発生すると思われます。このようなサーバを構築・運用する場面で以下のような経験をされた方はいないでしょうか？たとえば IaC等で構築自動化しているが自動化→人による作業→自動化→人による作業と合間に人の手による作業が介在してしまっている この人の手による作業に依存関係があり、しばしば作業漏れやミスが発生してしまう あるいは人の手による作業で作業者にコンテキストスイッチが多々発生してしまい他の仕事に集中できない。 etc., etc… 構成が複雑になりがちなデータベースサーバでは、複数台のサーバ構築をしているとDBの構築をしているだけで一日が終わってしまったということも目にしたり、筆者自身も経験したことがあります。 マネージドも解ですが これらを解決するものの一つとして、AWSのRDSやAurora、GCPのCloudSQLやAlloyDBなど、マネージド・サービスを使うことがあります。しかしながら、構成の自由度から独自にVMを構築し運用することはMySQL等に限らずシステム運用においては発生しうるものと思われます。我々のチームが担当するシステムでも、GCPにおいてMySQLをオンプレミスに構築し運用しています。ここでできる限り構築や運用の負担を軽減するために人手を極力介さずに自律的なサーバー構築が行いたいというモチベーションのもとIaCを活用して運用しているものを今回のシリーズものの投稿で紹介したいと思います。コンセプトの概要 自律的なサーバ構築を行う仕組みのコン

はじめに この記事を見つけたけど、後で見ようと思ったそこのあなた！ぜひ下のボタンから、ハッシュタグ #ハマグリ式 でツイートしておきましょう！ こんにちハマグリ。貝藤らんまだぞ。 今回は AWS および Terraform の上級者向けに、ハマグリ式！ Terraform での transpose 関数の使いみちをご紹介します！ 上級者って？ ハマグリ式では、下記のようにレベルを設定しています。 初級者：初めてクラウドサービスを利用する人で、基本的な操作（例：ファイルの保存や、サーバーの起動）をインターフェースを通じて行うことができます。また、シンプルなセキュリティルールの設定や、一部の問題のトラブルシューティングに対応できます。 中級者：より深い知識を持ち、コードを用いて操作を自動化したり、より複雑なタスク（例：自動でサーバーの数を増減させる）を行います。また、より高度な監視や、全体のシステム設計と実装について理解があります。 上級者：幅広く深い知識を持ち、大規模で複雑なシステムを設計、実装、維持する能力があります。最先端のテクノロジーを活用し、安全性、耐障害性、効率性を最大化するためのソリューションを提供します。 なお上記は ChatGPT による出力ですが、この記事でほかに生成 AI によって出力された文章はありません。ただし、Terraform や Python などのコードは生成 AI の出力を一部利用しています。ハマグリ式って？ 貝藤らんまが作成するブログ記事のブランド名です。あまり気にせず読み飛ばしてください。何を書くの？ 以下の通りです。 この記事で扱うツール $ terraform --version Terraform v1.5.3 on linux_amd64 + provider registry.terraform.io/hashicorp/aws v5.7.0 $ python --version Python 3.10.6 この記事で書くこと AWS を例とした、Terraform での transpose 関数の使いみち (効果的な Terraform 設計) この記事で書かないこと Terraform 組み込み関数の仕様説明 Terraform の基礎 Terraform のディレクトリデザイン サンプルコード 構築のベストプラクテ

yotaです。本ブログでたびたび話題に上がっている Visual Studio Codeのdevcontainerの機能を私も常用しています。なかでもdevcontainerの機能の一部であるDev Container Features が、チームで必須のツールとは別に個人的に使いたいツールをdevcontainerに導入する際に便利だと感じたので紹介します。Dev Container Featuresとは Dev Container Features で触れられていますが、Dev Container Featuresとは既存のimageにないツールを追加してdevcontainerを作ることを簡単に実現できる機能です。Dockerでは通常以下のような Dockerfile を構成して所望のツールが入ったコンテナを作るアプローチを取りますが、FROMubuntu# ubuntuイメージに追加のアプリケーションをinstallするRUN apt-get install -y xxxx Dev Container Featuresではツールのインストール処理のみを配布しておくことで、 devcontainerの設定ファイルである devcontainer.json で組み合わせることを可能にします。例えば、Ubuntu上にGolang（1.18）がインストールされたdevcontainerは、次のような設定で実現できます。{ "name": "golang-on-ubuntu", "image": "ubuntu", "features": { "ghcr.io/devcontainers/features/go:1.0.0": { "version": "1.18" } } } features フィールドで前述の「ツールのインストール処理」の配布場所を指定する形です（複数指定可能）。他のFeatures 基本的には Dockerfile でインストールしなければホストOS上で使っているツールはコンテナ内で使えません。 ホストOS上ではインストールしているツールをコンテナ内で使いたいが、そのためにDockerfileを書くのも手間、ということがままあったのですが、featuresによって簡単にインストールできるので重宝しています。1例えば GitHub Flavore

はじめに この記事を見つけたけど、後で見ようと思ったそこのあなた！ぜひ下のボタンから、ハッシュタグ #ハマグリ式 でツイートしておきましょう！ こんにちハマグリ。貝藤らんまだぞ。 今回は AWS および Terraform の中級者向けに、ハマグリ式！ AWS で使う Terraform の落とし穴をご紹介します！ 中級者って？ ハマグリ式では、下記のようにレベルを設定しています。 初級者：初めてクラウドサービスを利用する人で、基本的な操作（例：ファイルの保存や、サーバーの起動）をインターフェースを通じて行うことができます。また、シンプルなセキュリティルールの設定や、一部の問題のトラブルシューティングに対応できます。 中級者：より深い知識を持ち、コードを用いて操作を自動化したり、より複雑なタスク（例：自動でサーバーの数を増減させる）を行います。また、より高度な監視や、全体のシステム設計と実装について理解があります。 上級者：幅広く深い知識を持ち、大規模で複雑なシステムを設計、実装、維持する能力があります。最先端のテクノロジーを活用し、安全性、耐障害性、効率性を最大化するためのソリューションを提供します。 なお上記は ChatGPT による出力ですが、この記事でほかに生成 AI によって出力された文章はありません。ただし、Terraform のコードは生成 AI の出力を一部利用しています。ハマグリ式って？ 貝藤らんまが作成するブログ記事のブランド名です。あまり気にせず読み飛ばしてください。何を書くの？ 以下の通りです。 この記事で扱うツール $ terraform --version Terraform v1.5.1 on linux_amd64 + provider registry.terraform.io/hashicorp/aws v5.5.0 この記事で書くこと AWS の構築で Terraform を使う場合の落とし穴 (気を付ておかないと困ったことになるもの) この記事で書かないこと Terraform の基礎 Terraform のディレクトリデザイン サンプルコード 構築のベストプラクティス 免責事項 この記事に書かれていることは弊社の意見を代表するものではありません。 この記事に書かれていることには一定の調査と検証を実施しておりますが、間違いが存

皆さん、こんにちは！新卒3年目のオバカムと言います。普段はクラウドを利用してソーシャルゲームのインフラを構築・管理しています。さて、データベースの運用をしていると、データベースの統合をしたくなる時ってありませんか？ データベースの統合といってもいくつか種類がありますが、今回はMySQLデータベースをホスティングしているサーバの統合について書きます。負荷分散のため水平分割していたデータベースを一つのサーバに戻したい、あるいはサーバインスタンスの料金削減のために複数のデータベースを相乗りしたい、そういったときにMySQLのマルチソースレプリケーション機能を使うと簡単にデータベースサーバーの統合ができます！環境 今回は以下の環境でデータベースサーバの統合をやりました。 MySQL 5.7 CentOS 7 構成としては少しレガシーですが、MySQL 8でもやることは大きくは変わらないです。構成 今回は統合したいデータベースサーバ・統合先データベースサーバともに1:1のレプリケーションがなされている状態でのマルチソースレプリケーションです。図にしてみるとこんな感じです。 青い背景のレプリケーションが1:1のレプリケーション、赤い背景のレプリケーションがマルチソースレプリケーションです。すでに本番環境で運用しているデータベースをメンテナンスなしで新しく構築したデータベースサーバへ統合しようとしている、そんな状況を想定しています。そのため統合したいデータベースサーバから直接レプリケーションせずいったんバックアップ用のデータベースレプリカサーバを挟んでレプリケーションします。やること レプリケーション元サーバの設定確認 今回のマルチソースレプリケーションはすでにレプリケーションを行っているサーバから実施するため、以下設定がオンになっているかを確認しましょう。 MySQL 8.0.26を境に確認する変数が変わっているので要注意です。# MySQL 5.7 log-slave-updates=ON # ~>MySQL 8.0.26 log-replica-updates=ON 統合するデータベースのダンプファイルをとる 統合するデータベースのダンプファイルを取ります。ダンプファイルを取得する際にはレプリケーションを一時停止しておくといいです。以下ではSQL実行スレッドだけを止めていま

はじめに GO言語をやっていないとイケてないという風潮に、あせるネバー・フレンズ・Tです。やる気を出すためにGO言語布教の名曲Write in GOをCC(Close Caption)押して聴き、バイブス全開で学習することをおすすめしておきます。今回は、GO言語のデバッガのdelveで、GO言語学習中に、はまったことを書きます。delveでDebianパッケージのバイナリをデバッグする 自分のように特定言語の初学者がなにか新しいプログラミング言語を習得する時、言語学習を大いにはかどらせてくれるデバッガには、いつも大変お世話になっております。GO言語のデバッガとしては、自分の観測範囲では2つあるようで、 gdbでGO言語でbuildしたバイナリをデバッグするやり方、 delveを使うやり方 となっているようです。噂でdelveはイケてるということを聞いたので、早速delveを使ってみました。ここでは簡単にDebian sidに入っているHugoを、delveでソースコードデバッグをしてみます。delveを使ってhugo version --logを動かしてみることにします。なお、 デバッグされる側のプログラムをdebugee（デバッギー）と呼びます。 Debianパッケージのデバッグにはデバッグパッケージの追加ダウンロードが必要になりますので、HowToGetABacktraceを参照してapt/sources.listファイルをdebian-debugリポジトリが参照できるように予めセットアップしたものとします では早速動かしてみましょう。まずは環境の確認です。Debianはちょうど6/10にStable版としてbookwormリリースしたばかりですが、記事を記載したのがその前でしたので、当時のDebian sidの環境もDeiban stableの環境も同じバージョンになっています。ちなみに現在確認するとDebian sidはtrixieと表示されます。$ lsb_release -a No LSB modules are available. Distributor ID: Debian Description: Debian GNU/Linux 12 (bookworm) Release: 12 Codename: bookworm デバッガのdelveと、d

シリーズ・すこしずつがんばる streaming data 処理の四回目です。 (初回はこちら)ステップを踏んですこしずつ進めていますので、ぜひ他の記事も見てみてください。今回は、streaming data 処理の他の例として Apache Flink を試してみます。Flink を触るのは今回はじめてです。Beam の他にどんなものがあるのかな? と調べてみると思った以上にいろいろとあり、その中で 比較的シンプルそう・スケールする・比較的新しそう ということで選択しました。ほんとうは Apache Spark を試そうと思っていたのですが、Spark Streaming Programming Guide を見ただけでつらく、断念しました…Flink application をつくる 今回は こちら の内容を参考にさせていただきました。動作の内容はほぼおなじで、(WSL ではなく) Docker Compose で起動している Flink を実行環境にしているところが違うくらいです。まずは Maven でテンプレを生成します。groupId artifactId はお好みに合わせて変えてください。$ mvn archetype:generate -D archetypeGroupId=org.apache.flink \ -DarchetypeArtifactId=flink-quickstart-java -DarchetypeVersion=1.16.0 \ -DgroupId=com.example -DartifactId=flink-qstart1 -Dversion=0.1 \ -Dpackage=flinkStart -DinteractiveMode=false そのまま build してみます。$ mvn clean package target/ 以下に jar ができます。上の例そのままであれば flink-qstart1-0.1.jar という名前で生成されているかと思います。

シリーズ・すこしずつがんばる streaming data 処理 (前回、前々回) の三回目です。Streaming で逐次処理をやってみる 前回の記事では、固定サイズのデータを一括処理するバッチ処理を扱いました。が、Apache Beam で実現できる streaming data の逐次処理は、見逃すことができない強力な機能です。batch ではあらかじめサイズのわかっている (有限の) データを一括で扱いますが、streaming ではサイズがわからない (無限の) データを逐次に処理します。今回はこれを試してみましょう。事前準備 今回は Pub/Sub からデータを読むので、そのための Google account と IAM 権限が必要です。以下のようにして、Pub/Sub topic をひとつ作成しておきます。gcloud pubsub topics create test-1 サンプル 前回はサンプルコードを download し、その中身を変更して動作させる方法を使いました。これは多くの場合いちばん手っ取り早いのですが、問題もあります。 余分なものが多く含まれていて、単純にサイズが大きい 必要になる software の version や framework など、実行するための環境が限られる ある程度の機能を網羅する目的を達成するために、処理が複雑になってしまっていて、知りたいことに集中できない また GCS などへの出力は実際の用途には合うのですが、手っ取り早く動作を経験したい場合などには、手元からの距離が遠いために理解に時間がかかりがちです。 今回は極力必要な部分まで削ぎ落とした例を目指し、ローカルで実行して stdout に情報を出力するのみのサンプルとしました。Google Cloud 上の Dataflow などの環境で動作させる場合は逆にもうひと手間必要ですので、その点ご注意ください。簡易にとは言いつつ Gradle は使います。build.gradle は、ここ のものを download し、使用しない以下の行を削除しておきます。implementation "org.

お久しぶりです、noseです。前回の投稿から約4か月ぶりとなってしまいました。普段はインフラエンジニアとしてスマートフォンゲームを中心にサーバ構築・運用・保守などを担当しています。(私が所属するチームの紹介はこちら)そんな私が、今回は2023年4月20日と21日に幕張メッセで開催された AWS Summit Tokyo 2023 の参加レポートを書きたいと思います！ 概要 今回のAWS Summitは4年ぶりのオフライン開催で、私自身も現地参加は初めてでした。サミット全体的な概要としては、 AWSが取り組んでいる問題についての紹介(環境問題に対しての対応等) 新しいサービスの紹介 各企業のAWS事例紹介 AWSスタートアップ向けのイベント この辺りの内容が中心となっていました。全体的にはAWS初中級向けの内容になっているように感じたので、AWSに詳しい方は初日の参加だけでも十分かもしれません。私はしっかり2日間参加したのですが、興味あるセッションに参加し始めると時間が足りないくらいでした。基本的な過ごし方としてはセッションに参加→空き時間に展示ブースを散策という形になりそうです。各企業のブースもエンジニアであれば触る機会がありそうな製品も多かったので、インフラエンジニアとしては是非参加しておきたいイベントかなと思いました。 参加セッション一覧 セッションはオンラインで後日公開されるとのことなのでご興味ある方はこちらのAWSのページを御覧いただければ情報を確認できると思います。今回は以下の参加セッションのうち、太字で記載したものをレポートしたいと思います。1日目 今踏み出す、変革への一歩 情シスの情シスによる情シスのための人材育成-リスキリングとそれに反する教育後回しジレンマ克服の具体策- テクノロジーが けん引するイノベーション：AWS の深化と進化(スペシャルセッション) 『バイオハザード ヴィレッジ ゴールドエディション』開発におけるクラウド活用のアプローチ NTT データが 8 年間一緒に歩んだリクルート様の AWS 共通基盤での挑戦の軌跡 Amazon の事例から学ぶ Observability 活用におけるベストプラクティス 2日目 アイデアを形にし、これまでにない価値を届ける AWS でゼロトラストを実現するためのアプローチ ニコニコでのクラウド活用、そ

TCP/IPスタックを改造!？ サービスの通信トラブルを解析する場合、弊社では通信パケットを取得して原因を探ることがあります。そういうことをやっていると、そのうちTCP/IPのやりとりについて途中で自由にパケットを弄れたらいいのに…という欲望がふつふつと湧いてくるときが来ます。それじゃぁとLinuxのネットワークスタックのソースコードに挑むと、これがささっと手軽に改造してなにかできるような作りではありません。さあ、困りました。改造への思いをぶつける方法を探る必要があります。というわけで、 ユーザランドで簡易のTCP/IPドライバが実装されており、 構造もわかりやすくて、簡単に改造できて、ささっと実験できそうなもの を探したところ、PyTCP(https://github.com/ccie18643/PyTCP)がありましたので、紹介します。いきなり余談：scapyはどうなの？ パケットを直接いじったものを送信するということであれば、CTFなどでおなじみのscapy(https://scapy.net/)というPython製のネットワーク用ツール（ライブラリ？）があるじゃない！という方もいらっしゃると思います。もちろん、思いのままのパケットを発生して挙動を伺うという用途であればscapyは非常に良いツールです。しかしながら、socketをlistenした状態で、TCP通信途中のパケットを誰にも(OSにも！)邪魔されずに弄って実験したい…となると、TCP/IPドライバそのものの挙動を変えたい衝動に駆られることでしょう！ここではそういう向きの人向けの話をします。実際の例 こちらに実際に起きた通信不具合のパケットのやり取りをwiresharkで図示したものを載せます。 TCPのやり取りをご存知の方はSYNのあとにはSYN-ACKが返却されてきて…と思われる方もいらっしゃると思います。しかし、現実にはSYNのあとに只のACKが返却されてきちゃうという現象が起きてます。見ての通り、SYNの再送のたびに只のACKが返ってくるという挙動です。現実はいつも小説より奇なりです！当方ACKもらったらRSTをちゃんと送ってるのに！これが発生すると、とあるサービスが刺さってしまい、お客様にエラーが見えてしまうという問題が発生してしまうので、アプリケーション側でなんとかしたいというのが今回の相

Kubernetes の利用シーンは幅広い用途に広がり、長期計画でカスタムアプリケーションを開発してデプロイする以外にも、ぱっと cluster にアプリケーションを入れて使ってみるといったことも多く見られるようになりました。単純なアプリケーションでは kubectl apply で済むものも多いですが、じゃっかん複雑な構成のものや、また変数を使って動作を変更したいときなどでは Helm がよく使われています。時々 Kubernetes について話しているときに、kubectl はよく使うことになったが helm はまだ慣れていないんだよねという声も聞かれるようになりました。ここでは、そういったケースでの kubectl -> helm 間のギャップを埋めることを想定して、Helm の全体感がわかって日常的に使えるようになるまでを 30 分くらいでちゃちゃっとやってみましょう。おさらい : kubectl kubectl は Kubernetes cluster (master) と会話するための cli です。cluster への権限を前提として、情報の取得や更新を行います。まずはこれができないと先に進めません。こういう感じで使います。$ kubectl get pods -n default 今回は GKE や minikube などですでに Kubernetes cluster の準備があり、ここまでは理解している・できているものとして先に進めます。とにかく Helm を使ってみる まず、手元で helm を使えるようにします。公式の install 手順 をご参照ください。macOS では brew、Windows では choco の方法が書かれています。kubectl は gcloud components で入れることもできますが、helm は見たところ無いようです。お手元の環境に合わせて install してください。

PEP668は突然やってきた pythonのスクリプト書いてるときに、OSに入っていないpythonのモジュールが必要になったらどうしてますか？いままで、自分は細かいこと考えず、すぐ使えればいいやと割り切って$ pip3 install --user ほしいモジュール名 って、いつもやってました（笑）。まあ、見るからに、野蛮ですね。ところが、先日久しぶりにDebian sidにはない無いモジュール（pycoingecko）が必要になって、いつものようにpip3を実行しました。そしたら突然のエラーですよ！$ pip3 install --user pycoingecko error: externally-managed-environment × This environment is externally managed ╰─> To install Python packages system-wide, try apt install python3-xyz, where xyz is the package you are trying to install. If you wish to install a non-Debian-packaged Python package, create a virtual environment using python3 -m venv path/to/venv. Then use path/to/venv/bin/python and path/to/venv/bin/pip. Make sure you have python3-full installed.

すこしずつがんばる streaming data 処理、前回 からのつづきです。目指していることの概要などは前回の内容をご覧ください。いちばんかんたんな pipeline を実装してみる さて、前回では定形として用意された template 機能から実行してみることで、Dataflow で処理を行うのがどのようなことかの感覚をつかみました。今回はそこから一歩進んで、想定した仕様にカスタマイズして処理を書くことを目指してみます。ハッキリ言ってここからが急にしんどいです。何がしんどいかは順に見ていきましょう…やってみよう Dataflow のプログラム、というか Apache Beam SDK は (少なくとも初見では) 単純なつくりではなく、かつそれ自体を使うための事前準備が多く必要な類のものです。今回は Java で こちらの document に沿って進めてみます。環境は、新しめの Java と maven が入ったものがあればよさそうです。構築手順に関しては長くなるのでここでは触れません。前回利用した、“Word Count” が例というかスタート地点として利用できそうなので、まずは上記 document にあるまま以下のように実行します。$ mvn archetype:generate \ -DarchetypeGroupId=org.apache.beam \ -DarchetypeArtifactId=beam-sdks-java-maven-archetypes-examples \ -DarchetypeVersion=2.46.0 \ -DgroupId=org.example \ -DartifactId=word-count-beam \ -Dversion="0.1" \ -Dpackage=org.apache.beam.examples \ -DinteractiveMode=false これで、Word Count のソースを含んだ開発環境が手元につくられます。大量のソースコードが download されます。非常にシンプルなものをつくりたい場合に、ここから必要なものだけを残して使うという作業だけでもちょっとした手間そうなので、もうすこし簡易なスタートがあるといいなと思いました。今回は不要なものは無視して、メインの処理を追ってみましょう。

パブリッククラウドでよくマネージドで提供されているサービスのうち、活用が大きなアドバンテージになると感じるものに、リアルタイムの逐次データ処理、streaming data 処理があります。これを実現するために、OSS はじめ多くのベンダーからもさまざまなものが提供されていますが、GCP で streaming data 処理といえばやっぱり Dataflow です。(独断と偏見)Streaming data 処理とは 単に streaming data 処理というとさまざまな単位や仕組みのものがありますが、ここではネットワーク等の IO から流れてくるデータを集めて逐次処理するようなものを扱うこととします。具体的な例 たとえば、こういった機能が効率的に実装できます。 エンドユーザーのログインイベントを集めてリアルタイムでアクティブユーザー数を計算する CPU 使用率などのモニタリング指標を集めて 5 分間隔の平均をグラフ化する 一日に一度、データベースのデータを集計する 最後のものは通常、どちらかというとバッチ処理と呼ばれるものですが、Dataflow (等) を使うと、こういったバッチ処理を効率的に実装することもできます。「いつくるかわからないデータを待ち受け、それをある程度の単位でまとめて、データの内容によって複数の処理をし、別のデータベースなどに保存するといった処理」は、ゼロから実装しようと思うとなかなかめんどうなものです。テストもとてもめんどうです。それが streaming data 処理フレームワークを使うことで、データ処理部分の実装に集中することができるようになります。Dataflow とは GCP で提供されているフルマネージドのデータ処理サービスです。https://cloud.google.com/dataflowApache Beam という OSS があり、これを利用して処理を実装することで、抽象化したデータを共通のパイプラインで処理できます。(というか Beam はもともと、Dataflow の framework を OSS 化したのがはじまりだったとか 1)Beam が support する IO、つまり入出力の種類は こちら にリストがあります。これらを input、output として間にいろんな処理を組み込むことができます。ただ

Windows container …? ホシイです。ふだんからひたすら container 技術についての情報を web で漁っていると、YouTube を開けば技術系の動画に混ざってコンテナ船舶 (実体) の動画もおすすめされるような状態であり、果てにはそれも視聴してしまいああこれはなるほどすごい技術だなあ。と感心したりなどする日々を過ごしております。そんな日々の中であっても、なかなか気づかないことはあるものです。あるときふと Windows container という言葉に行き当たったときに、おやとなりました。WSL などはふだんから触れる機会はありますが、Docker で Windows container? さらには Kubernetes でも Windows container? はて? となり、これはひとつ調べて・やってみたくなりましたという次第です。Windows container を Docker Desktop で実行するための条件 いくつかの条件をクリアすると、Windows container を Docker Desktop を使って実行できます。 (ここがこの記事のハイライトです) host が Windows であること host の Windows version に 互換性がある container image を選択する こと Docker Desktop で WSL 2 backed engine を有効に しない こと (後述) Windows (host) で Hyper-V、Container 機能が有効になっていること (後述) Windows 11 でも同様かなと思うのですが、確認できていません。今回の実験は Windows 10 で行っています。

日々GitHub上で管理されたファイルを編集していて欠かせないことの1つに「Pull Requestを作る」があります。Pull Request（以下プルリク）の説明文はMarkdown記法をサポートしているので、箇条書きやWeb上にあるドキュメントへリンクなどを気軽に書くことができます。ところで、プルリクの説明文やいわゆるREADME.mdのようなMarkdownで書かれた内容は直接GitHub上で表示されるのではなく1、別途HTMLに変換されて表示されます。 プルリク作成の画面ではMarkdownの編集モードとPreviewモードが別タブで用意されているのですが、本ブログ内でたびたび登場するVSCodeなどのエディタではMarkdown形式の内容とその描画結果を横に並べて確認しながら編集が可能なので、プレビューモードと編集モードを都度マウスで切り替えることが手間に感じることがあります。プルリクをローカルで作る そこで、プルリクの説明文をローカル環境で作成することにしました。…といっても、例えば body.md 等適当に命名したファイルに説明文を書き、都度プレビューするのみです。このファイルの中身をプルリクの説明文にそのまま転記してもよいのですが、GitHub CLI を使うと以下のコマンドでブラウザなしにプルリクが作成できるので重宝しています。# -F で説明文を記載したファイル名を指定 # --reviewerでレビュワーも併せて指定できる $ gh pr create --title "プルリクタイトル" -F ./body.md --reviewer someone GitHub Flavored Markdownもプレビューしたい 多くの場合前述の方法で問題ないのですが、不満に感じることが出てきました。それは、GitHub Flavored Markdownがプレビューできない場合があることです。GitHubのMarkdownは厳密にはGitHub Flavored Markdownと呼ばれるMarkdownの方言に従い、いくつかの拡張構文があります。基本的な内容はこちらにまとまっていて、私が個人的によく使うのは「プルリクエストの参照」です。 他にもこちらで触れられている「タスクリスト」（チェックボックス）をよく使いますが、いずれも少なくとも202301

こんにちは、ホシイです。これを読んでいるあなたは、自分が AI ではないという確たる自覚をお持ちでしょうか? 🤔無作為に並べ替えがしたい コロナ禍以降、わたしの所属するチームでは、オンラインでデイリーミーティングをしています。日々の状況・情報の共有について、チームメンバーがひとりずつ順に数分話すのですが、毎日順番がおなじだとつまらないので順番を変えるようにしています。最初の頃は心のなかでテキトーに順を決めていたのですが、なにしろ面倒ですし、議論が盛り上がったときなどは抜けてしまったりなんならおなじ人を二度呼んでしまうこともあったりしました。こういうのはまさに機械が得意なことです。ミーティング前に手元でぱっと node で実行できるように、JavaScript のワンライナーを書きました。["幸", "中原", "宮前", "川崎", "高津", "多摩", "麻生"].sort(() => Math.random() - .5) やっていることは非常に単純で、sort() に使われる比較で、内容 (名前文字列) を無視して毎回 random() で 1/2 の確率で基準を変動させています。これでランダムに順番が変わるでしょう。よしよしと 2、3 日これでやってみたのですが、どうも結果が偏っているように感じます。 手元で何度か実行してみると、体感でわかるくらいに。なんとなく、元の配列から順番が変わっていない要素が多いように感じるのです。実際に数千回ほど実行してカウントしてみると、ソート先の場所に大きく偏りがあることがわかりました。以下は、先頭の要素が最終的にそれぞれの位置に落ち着いた回数を示すグラフです。 多少の偏りはたのしめる要素ですが、これではちょっと極端です…。 また、端に近い要素 (先頭、末尾に近い要素) ほど偏っている様子がありました。考えてみるとたしかに、sort() するときに順番を変える比較基準が五分五分で毎回変わると、元の位置からあまり離れていかないような気もします。(sort の algorithm 次第ではありますが)そこで、以下のように処理を変えてみました。["幸", "中原", "宮前", "川崎", "高津", "多摩", "麻生"] .map(o => ({ n: o, r: Math.random() })).sort((a, b) ...

Helmにおけるテンプレートを別ファイルに分ける仕組み Helmで0とdefaultを区別するに引き続きHelmの話題です。 Helmでテンプレートを記述するとき、基本的には以前の記事のようにマニフェストのYAMLファイル内に直接記載しますが、時にはテンプレートを別のファイルに分けたい場合があります。例えば、複数マニフェスト間で共通のテンプレートを使いたい、ConfigMap/Secretを構成する設定内容を別のファイルで管理したいといった動機があります。このとき、Helmではいくつか選択肢があり、使いわけに躓いたのでまとめます。要約すると、 方法 使い分け template テンプレートを処理の内容で識別したい場合。ただし、基本的にincludeで良い include template に加えてテンプレート描画結果に対して追加の処理を行いたい場合 tpl テンプレートをファイル名で識別したい場合 と考えています。 以下に詳しく違いをまとめていきます。template と include helm create でchartを作成した際に生成されるテンプレートに例があるので見てみましょう。helm create template_test として作成したchartにある templates/_helpers.tpl 1 を見ると、{{-define"template_test.chart"-}}{{-printf"%s-%s".Chart.Name.Chart.Version|replace"+""_"|trunc63|trimSuffix"-"}}{{-end}}という部分があります。これにより、 define ～ end 間のテンプレートを template_test.chart という名前でinclude、または template で参照可能になります。このテンプレートでは、 .Chart.Name でchart名（今回はtemplate_test） .Chart.Version でchartのバージョン（Chart.yaml に記載の値。初期値は0.1.0） を展開します。 適当なConfigMapを作って試してみると、apiVersion:v1kind:ConfigMapdata:chart_name:|{{ include "template_test.

開発作業を中心に様々な用途で非常に便利な devcontainer 機能ですが、container 内 workspace の disk 性能が遅すぎる問題のために実用に耐えないといったことがあります。devcontainer において disk が遅いと感じるのはおそらく、host 側にある folder を開いて devcontainer を起動した際に、その folder が性能が低い filesystem で bind mount されるからです (と思っています)。かんたんな作業であれば気にならないのですが、身近なものでは npm install したようなときでもわりと気になりますし、大きな project の build となるとかなりの問題となることもあります。公式: Improve disk performance にも専用の項目があったりします。named volume を使って解決をしよう、という内容です。計測してみる では、bind mount と named volume でどのくらい違うのでしょうか? devcontainer.json に mount を追加して検証してみます。named volume nv-proj を mount し、user vscode から利用できるようにしています。bind mount は、devcontainer で自動的に mount される workspace (devcontainer.json を含む場所) を使用します (ので以下の設定には明示されていません)。{ "name": "Ubuntu", "build": { "dockerfile": "Dockerfile", }, "remoteUser": "vscode", "mounts": [ "source=nv-proj,target=${containerWorkspaceFolder}/named-volume,type=volume" ], "postCreateCommand": "sudo chown vscode:vscode named-volume" } mount で確認します。それぞれ fuse.

こんにちは、ChatGPT です。嘘です。ただの情シス部員のホシイです。エンジニア組織がある多くの会社ではよくあるように、弊社でも、エンジニアが自身の業務に係る内容を社内向けに発表する機会が様々あります。その中でもおおきなものが昨年の末に企画されておりまして、その場でお話をさせていただける貴重なひと枠をいただきました。ひとり一枠 50 分 (うち 10 分は質疑応答) となかなか長めのものでしたので準備がちょっと心配だったりもしたのですが、なんとか完走することができました。今日は、その場でお話ししたことをダイジェストでお送りしたいと思います。ぜんぶだと 70 スライドほどありちょっと長いのと、社内限定情報を削除したり、記事としての体裁に合うようにすこし編集を加えたりしています。また、社内版では “弊社らしい” 非常に素敵な背景がついていたのですが、残念ながらこの場では様々大人の事情により、白一色背景の味気ないスライドでお送りします。(イラストはよく いらすとや さんのものを使用させていただいております。ありがとうございます)※ 内容は一部のシステムでの一例であり、全社での取り組み・ポリシーではありません。 タイトルは、“15分でできるサーバー環境構築” としました。テスト環境や QA 環境など、サーバー環境構築ってしんどいものですよねという課題の確認から、近年のさまざまな仕組みの活用によりこれくらい楽にできる例がありますよというストーリーです。15 分というのは結果それくらいでできるようになりましたという数値なのですが、これは 15 分くらいの作業をがんばることでできるということではなく、実際にはコマンド (helm install) を打ってしまえば作業的には完了で、あとは待つだけです。今回 VM host ベースの環境から Kubernetes で動作するものに変えたのですが、アプリケーションの依存関係がじゃっかん複雑なため、環境構築完了までは Kubernetes の reconciliation を待つだけであるとはいえ、これが 15 分くらいかかるのです。 必要性が上がっている理由として、単に環境を増やしたいというモチベーション以外にも複数の事情があり、またその重要性が増してきています。 さまざまな現場がありますが、インフラ担当チームがわかれている現場では

あけましておめでとうございます。本ブログ。まだ開始して一年も経過していませんが、ようやくまわりはじめてきた感がしてきております。IT 関連企業界隈ではすっかり一般的になりました技術ブログの花盛りという様相ですが、弊弱小ブログもまだまだなんとかがんばっていきたい所存であります。ブログを開始してわたし自身さまざま勉強になったこともあり、他社様で同様の業務に携っておられるかたも増えてきていることと思われますので、今日は、このブログがどのように運営されているか、システムや人の面を含めて少しご紹介できたらと思います。システム・制作プロセス まず、肝心のブログシステムとしては Hugo を採用しています。cgi 的にサーバーで動作してページを配信するのではなく、手元で build を行うとサイトに必要な file 群を生成してくれる仕組みになっていて、あとはそれを静的に hosting するだけで済みます。これまでブログ運営をしたことのなかったわたしにとっては、これだけでも新鮮で勉強になりました。このタイプのもの自体他にも複数種類あったりしますが、その中でも Hugo を選定した理由としては、すこし触ってみた段階で直感的なところがよさそうに感じたことと、すでに以前使ったことがある人がいたことあたりが決め手になりました。記事はすべて markdown で書かれていまして、サイト生成に必要なものはその記事も含めて GitLab で管理しています。記事を書いている間は Hugo が持っている server 機能を使うことで手元ですぐに確認ができ、非常に便利です。記事を書く人がおのおので記事内で使う画像も用意していて、GitLab 上でまとめて review されるようになっています。サイトを build したら、まずは container image として build し、それを preview、staging サイトに反映させています。現状 CI/CD の準備が間に合っておらず、このあたりは手で行っています。container の実行環境としては、今回はたまたまふだん使っている GKE cluster がありましたので、そこを間借りして専用の namespace をつくり、使用しています。この環境ではもともとアクセス制限も準備していたので、その準備の手間が省けたのはたすかりました

この記事はAWS for Games Advent Calendar 2022の25日目の記事です。皆さんはログの扱いに慣れておりますでしょうか？必要なログは全て綺麗に ETL していつでもばっちり見れる状態です！ となっていればどんなに良いことか、、中々後回しにされがちな部分かと思います。弊社でも様々なゲームが平行稼働している中、 大量のログがローテートされてサーバから消えていく タイトル別でうまくいい感じに一か所で管理したい 何かインシデントが起きた時、急いでいる時にサーバに SSH してログを漁りたくない さっと見れるようにしたい みたいな話がありつつも、中々手を付けられずにいました(主に syslog 周り)。今回 AWS さんの協力もあり、技術取得の一環で検証をスタートしてみました。「ログを S3 に集めて、 Glue でなんやかんや加工してみて、 Athena でいい感じに閲覧してみたい。」 みたいなことを考えている人には刺さるかもしれない内容となっています。本題 今回、収集対象としたログは「 audit 」「 messages 」「 secure 」「 nginx ( access , error ) 」の4つです。ゲームログも集めてみたいな～と思いつつ、まずは検証としてわかりやすい syslog 周りからやってみました。※ただし、後半のログの加工は audit ログのみとなっております。(すべてを検証しきれず。。) ご了承頂ければと思います。全体フロー 早速ですが、結論から。最終的には(現時点で)以下のような構成になりました。 順を追って説明します。収集 まずは各サーバからログを集めて S3 バケットに格納するまでの部分です。図でいうと、以下の部分となります。 ここではあまり難しいことはしておらず、

開発環境としての Windows に興味が尽きないホシイです。WSL が使いやすくなり、Linux を target とした server application の開発環境としての Windows 活用も、すこし様子が変わってきているように感じます。ゲーム開発などでの Windows 活用の有用性は言うまでも無いですが、かたや、特に我々のように本番環境の target を Linux としている backend engineer 向けには、Windows を使うこと自体が足かせとなることもままあることには注意が必要でしょう。(もちろん、Windows Server を使用している場合はまったくその限りではありません。)2022 と題したわりには古い話ばかりだったりしますが、年の瀬ということで、今回はそれらについてまとめてみたいと思います。Windows 問題の例 CRLF 問題 Windows では標準の改行コードが CRLF (\r\n)、Linux では LF (\n) であり、そのまま使用すると一部の状況で問題となることがあります。たとえば、shell script の shebang です。#!/bin/sh(CRLF) このように、一行目に書いておくことで interpreter を指定するものですが、上記のように CRLF で終わっていると shell が /bin/sh(CR) を探してしまい、そんなものはありませんよ、となってしまいます。❯ ./test.sh zsh: ./test.sh: bad interpreter: /bin/sh^M: no such file or directory これを解決するには、以下のようにします。※ 実行形式 binary file などにも適用してしまうとこわれてしまうので対象に注意しましょう

備えあれば憂いなし web サービスを運用していると、不測の事態というのは起きるものです。プログラムのバグであったり、ハードウェアの障害や性能不足であったり、時には理由がわからないが何かしら動かない、でも早急になんとかしないといけない… なんていうことが。もちろん、事前の準備は万全にしつつ、そういったことが起きないことが最善ではありますが、起きたときのために備えておくのもたいせつなことです。今回は “HTTP で送られた request 内容を見て、条件によって処理する backend をわけたい” という仮想シナリオをたて、これをなるべくかんたん・じゅうなんに解決できる手段を考えてみます。Envoy? 近年様々な用途で使われている高機能 proxy、Envoy。きっと Envoy ならこんな要求なんてかんたんにこたえてくれるだろう。という期待を持って軽い気持ちではじめましたが、結果を先に言うと非常に苦労しました。もし本番環境で問題が発生してから準備をはじめていたら… とぞっとします。今回は心に余裕を持って。では、やってみましょう。以下、先日 install した Rancher Desktop の環境 を使い、Docker Compose で Envoy、Nginx container を起動して相互通信しています。Envoy の設定を書く さっそく、Envoy の設定をつくります。これさえできれば終わったようなものですが、これがたいへんでした。今回は “じゅうなんに” ということで、Lua filter を使います。Lua で request、response の処理を組めばかなりいろんなことができるようですが、これを実現する例や document がなかなか見つからず、非常に苦労しました。以下に動作する envoy.yaml を置いておきますので、試行錯誤や様々な要件に合わせての検証にご利用ください。HTTP request から JSON POST body を受け取り、そこに特定の文字列 (例では “1234”) が含まれていたら特定の backend に route させるという例になっています。admin:address:socket_address:{address: 0.0.0.0, port_value:9901}static_resources

Helm Kubernetes (k8s)のパッケージ管理を行うアプリケーションとしてHelmがあります。 Helmではテンプレートによって使うimageのタグやDeploymentのPodの数といった設定値をデプロイ時に注入することが可能になっています。Helmのこのテンプレートファイル群の単位をchartと呼びますが、私のチームでchartを管理する中でoptionalなパラメータを表現しようとして躓いたのでまとめます。chartの設計上、optionalなパラメータをhelm templateで表現する必要がない場合が多いと思われますが、要件の都合や運用の都合で明確に区別したいという場合に参考になれば幸いです。やりたいこと Helmで注入する設定値 values.yaml が以下のような構造になっているとします。setting:foo:100bar:"test string"このとき、この値を注入したJSONファイルをConfigMapとして作成したいです。{ "foo": "100", "bar": "test string" } そのためには、以下のようなテンプレートを用意すればいいです。--- apiVersion: v1 kind: ConfigMap metadata: name: sample data: sample.json: |- { "foo": {{ .Values.setting.foo | quote }}, "bar": {{ .Values.setting.bar | quote }} }実際にテンプレート処理を試してみましょう。> helm template ./sample-chart --- # Source: sample-chart/templates/sample.yaml apiVersion: v1 kind: ConfigMap metadata: name: sample data: sample.json: |- { "foo": "100", "bar": "test string" } 問題なさそうです。 ところで、我々のアプリケーションではfooは多くの場合で数値ですが、いわゆるnullの意味を持たせて "foo": "" と設定したい場合もありました。

はじめに こんにちは、情報システム部 SRE 橋本です。普段はクラウドエンジニア(SRE)としてチームリードをしています。興味関心がインフラ、Observability、SRE、Security、Golangといった分野であり、 Japan Google Cloud Usergroup for Enterprise(Jagu’e’r ジャガーと読みます)でObservability/SRE分科会のオーナーを担当させていただいております。その縁もあって先日Innovators Hive at Cloud Next 2022でコミュニティ運営についてお話をさせていただきました。この記事では現在チームリードをしていてビルドアップ中でもあるSREチームについて考えていることをお話したいと思います。 また、このSREチームについてのインタビュー記事も掲載いたしました。メンバーやチームの雰囲気を伝えたいと思って作っておりますので、よろしければご覧ください。本記事は以前Jagu’e’r分科会で発表した資料を交えてお話をします。内容はシステムやSREとしてやることというよりも、チームや組織についての現在での考え方に重きをおいて書いています。我々のSREチームについて タイトルに”とあるシステム”とつけているのは、当社ではゲームやシステムによっていくつかのインフラチームが存在しており、その一部のチームやシステムであることを意味しています。あくまで一部でのSREに関することを書いており、スクエニ全体での取り組みではない点をご承知おきください。我々は下の図で吹き出しがついているスマートフォン系のバックエンドシステムを担当するチームになります。 システムと組織の変遷・クラウドネイティブ化との関わり システムと開発チーム・インフラチームの関係性 下図はシステムとそれを取り巻く組織の遷移を簡単な図にしたものです。一番左側の列ですが自社のデータセンタ（DC）でインフラエンジニア（図のInfra Engrs）がサーバ等のインフラを構築し、開発エンジニア（図のS/W Engrs）がプログラムをデプロイしてサービスを提供している様子を図式化したものです。ビルが立ち並んだアイコンはDCをイメージして貼り付けています。真ん中の列はDCがクラウド（雲の形のアイコン）に変わっています。2010年代からさまざま

日常的に Docker Desktop を使って快適にお仕事しているホシイです。しかし Docker をそう頻繁には使わない方や、エンジニアでない方に実行環境を渡したいだけなので単に実行するだけでよいとかいった用途に、Docker Desktop 以外の (ライセンスの縛りが無い・ゆるい) 選択肢もほしいという声を時折聞くようになりました。そこで… Rancher Desktop? 折しも Docker Desktop の値上げニュースが話題になってもおり、Rancher Desktop でもおなじようなことができると聞いたので、今回はその使用感を試してみたいと思います。ただし業務で使っている環境はこわしたくなく、今回使ったのは私物 PC の Ubuntu Desktop 環境、先日 upgrade した version 22.10 です。いくつかのことを検証しましたが、機能的には Windows などで使うのとそう差はないのではないかと思います。(WSL と組み合わせての部分が今回は検証できていないですが…)ではいってみましょう。既存 Docker の uninstall まずはもともと入っている Docker を根こそぎ消します。apt で入れていたので、そのまま 公式手順 に従って実施します。基本的には apt purge するだけですね。nerdctl + containerd を試す 次に、本題からすこしそれますが、nerdctl + containerd という構成も試してみたく、こちらを先にやってみました。これもさほど迷うことはなく、こちらの Install 手順 に沿って進めます。依存関係で必要なものがすこしわかりづらかったのですが、わたしの環境では以下が不足していて追加しました。環境によってご調整ください。 apt install するもの containernetworking-plugins rootlesskit slirp4netns BuildKit https://github.

スクウェア・エニックスで多分サーバーエンジニアと呼ばれるお仕事をしているBです。 オンプレミス環境でDockerやPodmanのコンテナを利用していると、プライベートレジストリを建てる必要性が出てくる場合があります。 そして、プライベートレジストリを建てると今度は安定した稼働のために、ミラーレジストリ的な何かを建てたくなるかと思います。今回は、完全なミラーレジストリとはいきませんが、キャッシュレジストリを簡単に建てる方法をご紹介します。キャッシュレジストリに何を使用するか レジストリを簡単に建てる方法として、Docker Registry があります。 本当に簡単で、最低限の設定であれば次のコマンドでサービスを立ち上げることができます。$ docker run -d -p 5000:5000 --name registry registry このDocker Registryはキャッシュ機能も備わっています。 Mirroring Docker Hub のページを見ると、 次のように設定すれば良いと書いてあります。 Configure the cacheTo configure a Registry to run as a pull through cache, the addition of a proxy section is required to the config file. To access private images on the Docker Hub, a username and password can be supplied.proxy:remoteurl:https://registry-1.docker.iousername:[username]password:[password] 一見すると、ページ名と見出しの通り、Docker Hubに対してのみ働くキャッシュ機能のようですが、実はその他のレジストリに対しても認証含めて問題なく機能します。 (この機能があまり知られていないようなので、今回この記事を書いています。)

こんにちは。未だに競馬で当たったことがないホシイです。今日も、クラウド機能をお手軽に使ってみるお試しネタをひとつお届けします。オンプレでも Cloud Logging を使いたい… ふだん GCE や GKE を使っていると、非常にすんなり Cloud Logging に log が入ってくれるので、オンプレサーバーを扱っているときにもこれが欲しくなります。というか、なんで無いんだ！という気持ちになります。たとえば httpd の log を Cloud Logging で見たい！だけなのに、一直線のサンプルが見つからなかったのでつくってみました。container でお試しセットをつくる いつも思うんですが、目的の最小構成がすぐに確認できる container image があると便利だと思うんです。 ということで、container でやってみます。 今回はオンプレで使っているちょっと古めのサービスを想定して、最近活躍を見る機会が減ってきた (個人の感想)、Apache2 httpd さんを使ってみましょう。以下のように、Fluent Bit と Apache2 を入れた Dockerfile をつくります。FROMubuntuRUN apt update && DEBIAN_FRONTEND=noninteractive apt -y install --no-install-recommends \ sudo git netcat wget gnupg ca-certificates apache2 && \ # Add user & group groupadd demo && \ useradd demo -g demo -m -s /bin/bash && \ echo "demo ALL=(ALL) NOPASSWD: ALL" >> /etc/sudoers && \ echo "done.

Cloud Functions GCPが提供しているFaaS（Function as a Service）にCloud Functionsがあります。これは、Googleが管理するインフラのもと、ユーザが登録したソースコード（関数）を実行してくれるサービスで、2022年9月現在、以下の言語をランタイムとしてサポートしています。1 Node.js Python Go Java .NET Core Ruby PHP 私のチームではGoを使ってFunctionを実装しているのですが、この記事ではその際のローカル開発環境について紹介します。 以降、本稿ではソースコード中の関数は「関数」、GCP上のCloud Functionsにおけるリソースとしての関数は「Function」と表現します。ローカル開発環境 ローカルでの開発（Cloud Functionsのドキュメント）より、 関数をローカルで実行するには、Function Frameworks または Cloud Native Buildpacks を使用します。 とのことなので、今回はFunction Frameworksを使います。Go言語におけるFunction Frameworkのリポジトリは https://github.com/GoogleCloudPlatform/functions-framework-go です。2022年9月現在、Cloud FunctionsにおけるGoの推奨バージョンは1.16です。 Go 1.16以降ではデフォルトではModuleモードがデフォルトに、依存関係の追加には go install より go get が推奨されるようになった 2 ので、以下の手順でモジュールを作成、及び依存関係の追加を行います。$ go mod init example.com/gcp_sample_func $ go get github.com/GoogleCloudPlatform/functions-framework-go/funcframework $ grep functions-framework-go go.mod require github.com/GoogleCloudPlatform/functions-framework-go v1.6.1 Hello World Goランタ

ホシイです。Docker の利用シーンが増え、IaC の出番が増え、… で確実に増えたのが、shell script を書く時間です。以前はそんなに書いていなかったのでテキトーに済ませてきたのですが、調べるたびに便利な機能があるものですね。bash script を書いていて、アレ、どうやって書くんだっけ… ということが非常によくあります。今回はそんな便利小ネタを (すぐに忘れてしまう自分の備忘のために) 書き出してみました。独断と偏見の、わたしのお気に入りセレクションで失礼いたします。変数文字列から一部を取り出す 変数に file name が入っているが、その拡張子をはずしたいということがよくあります。$ A=aa.tar.temp && echo ${A%.*} aa.tar ${...} の中で % を使っているのが、変数値の右端から pattern match した部分を削除するという意味になっています。類似で %% や # ## などもあります。変数値に文字列を足した文字列を追加する file name に何かを足して cp したいみたいなこともよくあります。$ cp temp.txt temp.txt.b これは、以下のように短く書けます。$ cp temp.txt{,.b} これだけで、temp.txt.b にコピーされます。同様に、, の左右を入れ替えると逆 (末尾を削除) もできます。ひとつ前のコマンド引数を再利用する とにかく、おなじことを二度書くのがめんどうだったり、↑ ↑ とやって history に探し当てても file name などの直値が入っていると置き換えないといけなくて使いにくいことってありますよね。$ mkdir -p temp/temp/temp $ cd $_ $_ はひとつ前のコマンドの最後の引数をあらわします。これにより、mkdir した先に cd できます。

はじめに 今日もせっせとlinuxマシンを情報シス業務で日夜触りまくっているネバー・フレンズ・Tです。 今回はみんな大好きUbuntu/Debian系のaptコマンドのデバッグの仕方についてちょこっと書いてみます。実はaptはデバッグしやすい apt-get source aptして取ってこれるaptのC++のソースコードを眺めていると、ソースコードの要所要所でデバッグ用の仕掛けが入っていることに気が付きます。この仕掛けを利用すると、いろいろ気の利いたところでデバッグ出力をさせることができますので、なにかaptの問題に遭遇したらちょこっと試してみるのも良いかもしれません。まずはaptの設定内容を見る aptにどういった設定がなされているか？はデバッグ開始前に確認しておいたほうが良いです。こんな時に便利なコマンドとしてapt-config dumpがあります。$ apt-config dump APT ""; APT::Architecture "amd64"; APT::Build-Essential ""; APT::Build-Essential:: "build-essential"; APT::Install-Recommends "1"; APT::Install-Suggests "0"; APT::Sandbox ""; APT::Sandbox::User "_apt"; APT::Authentication ""; APT::Authentication::TrustCDROM "true"; APT::NeverAutoRemove ""; APT::NeverAutoRemove:: "^firmware-linux.*"; APT::NeverAutoRemove:: "^linux-firmware$"; ...後略... aptのソースコードでも、apt-config dumpで出てくるような形式の文字列でフラグのON/OFFを確認しています。実際の例：_config->FindB("Debug::pkgAcquire"... なお、ソース中のこのフラグ確認部分ですが、オプションの名前については大文字小文字を無視した判定(stringcasecmp():apt-2.5.3/apt-pkg/contrib/strutl.cc)をしているの

オブザーバビリティー? “observability” という言葉をよく聞くようになりました。以前よりは、ですが。長くて、カタカナで書いても正しく書けたか自信がないです。上に書いたのも、変換をミスったりして二度ほど書き直しました。そもそも手元の IME で変換できていないような気がしています。Internationalization を i18n と書くように、o11y という表現もあるようですが、もう何がなんだかです。意味合いとしては、システムの “見える化” を進めようよ、ということと捉えています。サーバーで動くシステムが複雑になると、どんどん内在する問題が見えにくくなっています。様々なデータを集めて可視化することで問題の早期発見やパフォーマンスの改善に活用していきたいところです。マイクロサービスのボトルネック…? 機能を細分化するメリットももちろんありつつ、問題が起きたときにその調査が難しくなるようなことも多いです。 たとえばある API が妙に時間がかかっているというときに、API 処理の CPU 時間が原因なのか、そこからの DB 処理待ちなのか、ファイル書き込みが遅いのか、… などなど、原因特定に時間がかかることがあります。本番環境でしか発生しないようなことも多く、そういった要素が絡み合ってデバッグの難易度を高くします。今回は、Open Telemetry の Trace 機能を使って、どの処理にどれくらいの時間がかかっているのかをどのように視覚化できるか見てみようと思います。今回 GCP は使いますが Cloud Run などの GCP で利用可能なものに限ったものではなく、オンプレ等で動くカスタムアプリケーションにも仕込める想定でやってみます。プログラムへの組み込みが必要になってはしまいますが。そして相変わらずわたしの都合で例は nodejs です。注意点として、node 向けの Open Telemetry の library は完成度が他言語に比べてイマイチな印象で、かつ変更も早いようです。ともあれ言語の選択要件はシステムによってさまざまですので、ここでの例は “例” としてご参照いただければと思います。サンプル！ 忙しい人のためにしては前置きが長くなりすぎました。ここで一気にスピードを上げて、いなきりサンプルコードを出して完結したいと思います。

はじめに 昨今UEFI対応BIOS+SecureBootネタに執心のネバー・フレンズ・Tです。Linuxを相手にしたUEFI対応BIOS+SecureBoot仕様の操作の練習（試行錯誤）を安全にやりたい方向けに手元の仮想環境(kvm)で実際にUEFI対応BIOSを動かし、SecureBootを有効にしてDebianを対象にブートの設定だけ手組してみることを語ってみます。こちらに慣れておけば、以降はお好きにUEFIの実験ができるようになり、理解が進むのでは？と思ってます。UEFI対応BIOS+SecureBoot(Debian デフォルト起動編)の概略図とEFI Variable いままでレガシーBIOS Bootばかり触ってきた人にありがちなのですが、巷のUEFIの解説やLinuxのUEFI Bootの解説、断片的なUEFI関係のblogやwikiを見て、あまりに断片的な内容が多いためか理解するのに心折られた方も多いかと思います。かくいう自分もその一人で、わけがわからないよ！と正直思ってました。UEFI対応BOISとSecureBootの起動についてぜんぜんわからない俺はブートを雰囲気でやっている、ということから少しは抜け出してみます。まずは、Debianの起動からです。shim-unsignedパッケージのソースコード、及び、手元のDebian unstableの設定ファイルから、概略ですが、図に起こしてみました。 図中、EFI VariableがUEFI対応BOISのブートを制御する変数群となります。図に書ききれないため省略しておりますが、これら変数にはもれなくGUIDというIDが付属しており、このGUIDと変数名のペアで参照することになっています。実際にBootOrder変数を例にLinuxから見てみます。Linux環境はDebian(unstable)となります。$ sudo apt install efivar $ efivar -l | fgrep -i bootorder 8be4df61-93ca-11d2-aa0d-00e098032b8c-BootOrder $ efivar -L | fgrep 8be4df61 {8be4df61-93ca-11d2-aa0d-00e098032b8c} {global} efi_guid_global EF

ホシイです。こんにちは。あまりこういうことばかりを書いていると怒られそうですが、やっぱり有料ライセンスが必要なソフトウェアって使い始めるのに敷居を感じてしまいます。でも、本格的にチームに導入する前に container での開発をしばらく検証したいとか、年に数回しか使わないからライセンス費用を抑えたいという場合もあるかと思います。以前に、Docker push での事故を防ぎたい という記事を書きました。このときは有料ライセンスがあることを前提に、push するときには気をつけよう！というのが主題でした。Docker CE は Docker の Community Edition で、Linux で Docker を無料で使えます。今回は、Docker が業務になじむかわからないけど、まずは試してみたいな… という場合でも迷わずすぐにはじめられるように、WSL2 + Docker CE を使って container を利用できる環境構築をしてみましょう。※ 今回は Windows 10 を使用しています。Windows 11 をお使いのかたは (ほぼおなじだと思いますが)、適宜読み替えなどおねがいします。まずは WSL2 を使えるようにする PowerShell などを使い、WSL を有効にし、また、(WSL1 ではなく) WSL2 を default に設定しておきます。後者は必須ではありませんが、今回の内容では WSL1 では動かないハマりポイントがあるので、他で WSL1 をメインに使われているとかでなければ設定しておくのをおすすめします。PS C:\> wsl --install PS C:\> wsl --set-default-version 2 次に、Microsoft Store から以下二点を install しておきます。 Ubuntu 22.04 一度起動して install を完了しておく (一般 user をつくる) (おすすめ) Microsoft Terminal を入れる Ubuntu は MS Store に複数のバージョンがありますが、記事作成時点で最新の 22.

はじめに Linuxを今時のPCに入れて使ってるのにUEFI+SecureBoot経由じゃないのは小学生までと思うネバー・フレンズ・Tです。今回は早速SecureBootを使うようになって困った件と回避策について語ってみます。SecureBootではdyndbg機能が動かない!? なにかのデバイスをLinuxマシンに追加しようとして、うまく動かなくて大ハマリした経験はLinux使いの人だと誰しもあると思います。弊社でも山ほどの物理マシンに搭載したLinux機がありますので、そういう問題に直面することがあります。まあ、大体はベンダのサポートの皆様にヘルプを要請するとなんとかなることが多いですが、なんでもサポート契約のあるような機材ばかりと思うなよ？という状況に遭遇することがあります。例えば一時的に会社の民生品をつないで、動作させなければならない場合などでしょうか。ここで、外付けデバイスの調子が悪い場合に役に立つのがLinux kernelの持つデバイスドライバに搭載されているデバッグ用のログ出力(dyndbg機能) となります。ところが、今時のUEFI+SecureBootの環境と、特定のディストリビューションの組み合わせでは、dyndbg機能が封じられてしまっているという問題に直面することがあります。dyndbg機能が動かないことを確かめる 実際にUEFI+SecureBootで起動したDebian unstableでやってみます。現在SecureBootが有効か？をmokutilで確認してから、kernelのnet/ipv4/ping.cのデバッグ用ログを有効化してみます。$ uname -a Linux debian-sid 5.16.0-4-amd64 #1 SMP PREEMPT Debian 5.16.12-1 (2022-03-08) x86_64 GNU/Linux $ lsb_release -dirc Distributor ID: Debian Description: Debian GNU/Linux bookworm/sid Release: unstable Codename: sid $ sudo apt install mokutil $ mokutil --sb-state SecureBoot enabled Debianで、Sec

log を活用してシステムの可視化を進める 今回は Observability に関連する記事です。Observability といえば、以前にも custom metrics や trace を送信する方法を調査しました。今回は「アプリケーションに手を入れるのはしんどいのだが、log にはすでにある程度の情報を吐いているので、それを活用してシステムの可視化ができないだろうか」というシナリオを想定してできることを見てみます。GCP では Logs-based metrics という機能がありまして、かんたんに言うとこれを使ってみましょう、という内容です。前提として、GCP Operations Suite (旧 Stackdriver) に log を送信していることとします。Logs-based metrics を設定してみる 今回は、API サーバーが以下のような log を出力している想定としましょう。2022/03/15-09:30:41 - API call [sqex.api.user.readInfo] - 2022/03/15-09:30:42 - API call [sqex.api.user.readInfo] - 2022/03/15-09:30:43 - API call [sqex.api.user.writeInfo] - httpd でいう access_log のようなもので、日時と実行した API 名を log に出しています。一般的に、こういったものを出力するのはよくあることだと思います。上記リンクをはったページにもやりかたがありますが、GCP web console の Logs-based Metrics 機能に飛ぶと、あたらしく metrics を作成することができます。ここで、上記に例示しました log 出力に対して metrics を作成してみましょう。

はじめに ネバ―・フレンズ・Tです。Windows10+WSL2を使っていてGUIを無性に使いたくなるときってありません？今回はWindows10+WSL2+ubuntu 20.04+VNC+docker(moby版)でdebian unstableのGUI環境を動かしてはまったことを書きます。なお、未確認ですが、現在最新のubuntu 22.04では本ブログで語る問題は全部治っているハズ…なのでそこはご了承ください。dockerdまわりではまったらこうやってデバッグすることもある…ということで生暖かくみていただければと思います！Windows10+WSL2+ubuntu 20.04にdockerを手早く用意 Windows10+WSL2上のubuntu 20.04にdockerをさらっと用意します。apt一発でインストール完了、systemdを起動してsystemdのpidにnsenterしてからdockerdを起動するだけなので、超簡単ですね！1$ uname -a Linux your-machine 5.10.16.3-microsoft-standard-WSL2 #1 SMP Fri Apr 2 22:23:49 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux $ lsb_release -dirc Distributor ID: Ubuntu Description: Ubuntu 20.04.3 LTS Release: 20.04 Codename: focal $ sudo apt install systemd docker.io daemonize util-linux $ sudo usermod -a -G docker $USER $ sudo daemonize /usr/bin/unshare --fork --pid --mount-proc /lib/systemd/systemd --system-unit=basic.target $ SYSTEMD_PID_OUTER=$(ps -auxww | fgrep '/lib/systemd/systemd' | fgrep system-unit | fgrep -v unshare | awk '{print $2}' ) $ sudo nse

前置き ホシイです。web backend のようなシステムの開発には、container は必要不可欠な技術になるまでに存在感を増しています。container というとパッとつくってすぐに壊すというイメージがありますが、試行錯誤をサイクルさせる開発環境としての使い勝手はどうでしょうか。Visual Studio Code (以下 VS Code) の devcontainer は、開発環境を宣言的に整え・共有し、便利に利用できる、とても強力な機能です。今回はこの devcontainer の布教をします！今更か… という感もありますが、めんどうでまだ触れてない・どんなものか触ってかんたんに知りたい、という需要は意外とありそうに思われましたので、最速でメリットを感じることを目的にご紹介したいと思います。前提条件 以下、install & setup しておきます。 Visual Studio Code Docker Desktop (Docker Desktop であることは必須ではありませんが、ここでは単純化のためにこうさせてください) 手順 VS Code を起動し、作業用 folder (directory) を開く メニューから “File” > “Open Folder …” を選択します。 folder 選択 dialog が開いたら、あたらしく folder を作成し、その場所を開きます。devcontainer の設定を追加 command palette を開き (Ctrl + Shift + P / ⌘ + Shift + P)、以下のように進めます。 ”Remote-Containers: Add Development Container Configuration Files…” を選択 option の選択に進むので、Ubuntu > “ubuntu-22.

はじめまして、スクウェア・エニックスのBと申します。 Linux上で良く分からない内に使用している方が多いであろう機能として、D-Busがあります。 D-Busは、プロセス間通信を実現する方法としてメッセージバスを提供してくれます。名前からデスクトップ用途でしか使用することがないと思われる方もいるかもしれませんが、サーバ用途でも様々な箇所で使用されています。 例えば、SELinuxの関連でsetroubleshootというサービスがD-Busを利用しています。 これは、ポリシ違反に関する記録をもとに、その分析をおこなってくれるものです。過去に私は負荷試験の過程で、setroubleshootを暴走させてしまいました。 setroubleshootが悪い訳ではなく、ポリシの調整不足から、大量の違反をsetroubleshootに分析させ続けてしまう状況にしてしまいました。 そして、それを停止するために、setroubleshootの仕組みを調査しました。 その過程でD-Busの設定や動作状態についても簡単に確認する必要がありました。 ここでは、その際に活用したD-Bus用ツールによるD-Busの確認方法について主に取り上げます。setroubleshoot D-Busの確認方法について紹介する前に、setroubleshootについても簡単にではありますが説明します。 setroubleshootはその名の通り、SELinuxに関するトラブルシュートを補助してくれるサービスです。 少なくとも、Red Hat Enterprise Linux 8では最初から裏で稼働しています。setroubleshoot用のツールである sealert による情報の出力操作とその例です。 ポリシ違反内容やその回数、ポリシの修正方法等を比較的分かりやすい形式で表示してくれます。$ sealert -l '*' # 出力例: コンテナ内からホスト上にディレクトリ /home/testuser/tmp を作成しようとした場合 SELinux is preventing /usr/bin/coreutils from write access on the directory labeled user_home_dir_t. ***** Plugin catchall (100. confid

はじめに こんにちは。ネバ―・フレンズ・Tデス！WSL2便利ですね！Windows10を利用しなければならない環境で、なんとかしてLinuxの環境を手元に置きたいという願いは人類不変の願いです。今回はWSL2でauditdが動いてくれなかったので、無理矢理auditdを動かしてみた件を書きます。WSL2でaudit.logを取りたいっ WSL2のubuntu 20.04で、libseccomp2を活用したプログラムを検証していました。ここで、seccompで引っ掛かったのはどのsystem callか？を調べる必要が出てきました。どうもこの時のログの出力はaudit系の出力先にでるそうです。では、手元のWSL2でauditdが動けば/var/log/audit/audit.logにログを集めれるかも？と思いWSL2でauditdを動かしてみました。WSL2のubuntu20.04だとauditdは動かない… 早速auditdをWSL2のubuntu20.04で動かそうとしました。$ uname -a Linux your-machine 5.10.16.3-microsoft-standard-WSL2 #1 SMP Fri Apr 2 22:23:49 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux $ lsb_release -a Distributor ID: Ubuntu Description: Ubuntu 20.04.3 LTS Release: 20.04 Codename: focal $ sudo service auditd start * Starting audit daemon auditd [fail] failとありますので、動いてくれません…CONFIG_AUDITがOFFなのが怪しい WSL2のubuntu20.04ではjournaldすらも動いていないので、そのままではシステムに関するログは出ません。なぜauditdが動かないのかはログに頼らず調べる必要があります。$ sudo /sbin/auditd -n -f Config file /etc/audit/auditd.conf opened for parsing ...中略... distribute_network_parser cal

はじめに ネバ―・フレンズ・Tです。こんにちわ。大人の事情により、新しいLinux環境でどうしても古いpythonを動かしたいという件ってありませんか？私は普通にあります。ここでは、最新の環境(debian unstable)にて、python3.6を動かそうとしておおはまりした件をお話しようとおもいます。python3.6がSegmentaion fault pythonのいろいろなバージョンが欲しいときいろいろなpythonの仮想環境を作る方も多いと思います。自分は主にpyenvを使っています。今回どうしてもpython3.6の環境を用意する必要があり、以下のように最新のOSであるところのdebian unstableへインストールを試みました1。$ lsb-release -a Distributor ID: Debian Description: Debian GNU/Linux bookworm/sid Release: unstable Codename: sid $ gcc -v ...中略... Supported LTO compression algorithms: zlib zstd gcc version 11.2.0 (Debian 11.2.0-16) $ pyenv install -k 3.6.15 Downloading Python-3.6.15.tar.xz... -> https://www.python.org/ftp/python/3.6.15/Python-3.6.15.tar.xz Installing Python-3.6.15... BUILD FAILED (Debian unstable using python-build 2.1.0-12-g5963dc4f) Inspect or clean up the working tree at /home/yours/.pyenv/sources/3.6.15 Results logged to /tmp/python-build.20220222021843.38052.log Last 10 log lines: if test "xupgrade" !

ホシイです。本日は git の小ネタをひとつ。git commit されているものがいつもそのまま動くとは限らない 便利 script を git clone して、そのまま実行！したら、しょうもないエラーに … といったことは残念ながら、めずらしいことではありません。commit されているものがいつもただしいなんて、いつから錯覚していた…? なんて、よくあることです。レビュアーを責めても時間は返ってきません。たとえば設定ファイルを yaml で書いていたとして、その yaml に syntax error が残ったまま commit & push してしまった、なんていう経験はないでしょうか?こういった問題は作業者の気の緩みによって起きるものである、気合で解決だ！ …というのは難しいものです。commit 前にチェックしよう、自動で。 git には様々なタイミングでかんたんに hook 処理を追加することができます。git init された場所であれば、.git/hooks/ にすでに、いくつも sample を見つけることができます。たとえば .git/hooks/pre-commit.sample の中身を見ると、sh script でいくつかのチェックをして、失敗したときには exit 1 すればいいらしいことがわかります。pre-commit という名前なのですから、きっと commit 前に走って、失敗すれば commit も抑制されるのでしょう。今回の目的に合いそうです。試してみよう .git/hooks/pre-commit という名前で以下のような中身のファイルを作成しておきます。#!/bin/sh exit 1 これで、なんでもいいので試しに commit してみましょう。$ git commit fatal: cannot exec '.

はじめに 今日もクラウドサービスにサーバ作っているネバー・フレンズ・Tです。VPN利用がいろいろなところでカジュアルに叫ばれている中、VPNってどう動くんだろう？と思ったことはないでしょうか？自分もVPNがどう動くのかを、むつかしいことは抜きにもっと手軽に知りたい！と思ってました。今回はLinuxのtapデバイスを操って、AWS Client VPNやその他のVPNのソフトウェアを一切使わず、AWSに簡易VPNを手組みで建てて手元のLinux機と通信させることを試してみます。実は大仰なソフトウェアを使わなくても実はVPNってとっても簡単だね！ということを感じていただければうれしい次第です！VPNって重要だね！ いろいろな環境から遠くのコンピュータ資源を利用する手段としてVPNがあります。最近は多様性の世の中から、いろいろな事情でVPNをつかわざるを得ない機会も増えてきている状況です。通信の中身を見られないようにしてまるでLANをつなげているような感覚で遠隔地の計算資源を操作/通信できるわけですから、そりゃ便利です。いまだとリモートワーク全盛ですので、VPNの恩恵なしにはCOVID対策と商売も両立できませんでした。ただ、VPNのマニュアルを見ると、なんとなくどこもかしこも複雑そうですよね！だいたい複雑そうでブラックボックスな場所って、ちょっと放っておくと闇の使いからの脅威が入りやすい場所となってしまうのは、世間のお約束です。もし、使っているVPNが信用できなかったら…と思いをはせると、顔から冷や汗が吹き出し、心臓がキュンキュンするーっ！という気分になる人も多いと思ってます。自分も、まさか普段使っているVPNに闇の使いへのバックドアが開いていたら…と思うと、いろいろな心配事が交錯して夜も眠れません。でも、安心してください！いざとなったら自分が信用できる方法だけ使っても、手軽にVPNが作れることを知っておけばいいのです！原理は簡単 VPNの接続の様子を図にしました。 遠隔地のLANを何らかの方法でユーザの機材をつないでしまえればVPNはできてしまうということがわかれば、もうわかったも同然です。実は接続先に端末ログイン可能なLinuxマシンが１台あれば、これとユーザの機材をネットワークとしてつなぐことで、あっという間にVPNの出来上がりです。こういった用途に便利なのはlin

はじめに Windows Subsystem for Linux (WSL) はWindows環境で気軽にLinux環境を実現でき、便利なものです。Linuxのコマンドを気軽に実行できたり、Hyper-V同様にDocker Desktop for Windowsのバックエンドに指定できたりと便利な一方、WSLを使っているからこそ直面する問題もあります。本稿では、私が直面した問題についてまとめました。※ WSLは厳密にはWSL2とWSL1の2世代ありますが、ここではWSL2を対象にしています。DNS設定をカスタマイズしたい WSLのデフォルト設定では、WSL用に作成された仮想インタフェースがDNSサーバに設定されています。以下、PowerShell上の操作は PS > から、WSL上のシェルの操作は $ から記載することとします。 また、WSL上で扱うディストリビューションはUbuntuを例にしています。# Windows上 PS> ipconfig /all # より抜粋 イーサネット アダプター vEthernet (WSL): 接続固有の DNS サフィックス . . . . .: 説明. . . . . . . . . . . . . . . . .: Hyper-V Virtual Ethernet Adapter IPv4 アドレス . . . . .

Cloud Monitoring で Custom Metrics? GCP を使っていると、使っているリソースによって、たとえば GCE instance であれば CPU 使用率などの metrics が追加の設定無しで利用可能になっており、すぐに dashboard をつくって値を見ることができ、非常に便利です。これら標準で用意されている metrics と同様に、ユーザー定義の metrics もある程度の手間で利用でき、用途によっては非常に便利に活用できます。 今回はそんな例をひとつつくり、可能性を探ってみたいと思います。metrics 送信を実装する 今回は こちら の例をほとんどそのまま使います。わたしが慣れてて楽だからという理由で nodejs runtime を使います。Monitoring 用の module を install して…npm install --save @google-cloud/monitoring 以下ほとんど上記サンプルそのままですが一部だけ、label などをそれっぽく変えています。 後で使う https module も宣言しておきます。const https = require('https'); const monitoring = require('@google-cloud/monitoring'); const client = new monitoring.MetricServiceClient(); async function writeTimeSeriesData(v) { const dataPoint = { interval: { endTime: { seconds: Date.

概要 継続的インテグレーション、継続的デリバリー（CI/CD : Continuous Integration /Continuous Derivery)を実現するためのツールの1つであるConcourseについて、筆者が特にパイプラインを構成するアーキテクチャが面白いと思ったのでまとめてみました。Concourseとは Concourseとは、継続的インテグレーション、継続的デリバリー（CI/CD : Continuous Integration /Continuous Derivery)を実現するためのツールの1つです。公式ドキュメントでは、 設定がソースコードのように扱える YAMLファイル形式 パイプラインの処理の流れが可視化される 処理の流れがグラフ構造としてWeb UI上に表れる 再現性があり、デバッグも容易なビルド あらゆる処理がコンテナ上で実行されていて、専用CLIツールを用いてコンテナ内に入って検証できる（例えば失敗したビルドの原因の調査など） などが特徴としてあげられています。今回はその中でもConcourseのパイプラインを構築する上で重要な、 「Resource」という概念が面白いと思ったのでまとめてみます。Concourseにおけるパイプライン Concourseにおいて、パイプラインは以下の要素で構成されます。 Job 複数のTask、及びResrouceの入出力の組 Task 実際の計算処理（例：ソースコードのビルドなど） Resource Concourse内外の入出力を表すオブジェクト 特に私が面白いと感じているのはこのResourceの存在です。Concourseのドキュメントでも触れられているのですが、Concourseにはいわゆるプラグインのようなシステムではなく、代わりにそのパイプラインで注力したい さまざまな入出力をResourceとして抽象化 しています。 Concourse does not have a complex plugin system. Instead, it focuses on a single strong abstraction: resource, which are implemented by resource types.

ホシイです。Docker Desktop、便利ですよね。しかし、便利すぎるがゆえに問題になったり、そのために使えなくなったりしてしまったらたいへんです。普段から確認をしておきたい、というのが今回の趣旨です。Docker Desktop を sign in ありで使いたい? August 31, 2021 (January 31, 2022 まで猶予期間でした) より、Docker Dekstop の Windows 版と macOS 版は、一定の条件下の利用で有料ライセンスが必要になりました。さて、Docker account で sign in した状態で docker を使うに際し、気になることがあります。DockerHub に “間違って” image を公開しちゃったりしないでしょうか?わたしは業務では GCR (gcr.io) を利用することが多いので、image name には gcr.io/… といった指定をつけて運用していますが、たとえばこれをつけ忘れちゃったりしたらどうなるんでしょう?最近は手元にテスト環境をつくるようなツール類を container を使って用意していて、docker をふだん使わないメンバーにも使ってもらっていたりすることから、不意の操作で意図せず image が公開されてしまった… というような事故が起きないようにしておきたいです。秘密情報が含まれた container image が誤って公開状態で DockerHub に upload されてしまうと、情報セキュリティの問題になってしまいます。そこで、認証と repository の状態によって push の挙動がどのようになるか実験してみました。 以下、Organization に所属した Docker account を使って検証しています。問題がないケース 存在しない image repository への push は deny されます ❯ docker push test Using default tag: latest The push refers to repository [docker.

はじめに みなさんこんにちは。情報システム部のネバー・フレンズ・Tです。最近はブロックチェーンもはじめました。ここでは自分が担当した技術面で面白かった件を、問題の無い形に変えて（伏せたり、一部フィクションにしたりしてw 1 )、カジュアルにお送りします。スクエニ情シスの実際の業務の出来事をベースにしてますので、その雰囲気を十分に感じていただければと思います！ではゆるゆると、どぞー。はじまりはいつも… 「とあるpython3のコマンドが、エラーを起こして困ってる」という相談がslackで来ました。みんな大好きpython3。こちらについての相談です。スクエニの情シスは、社内・お客様サービス用のLinuxサーバも、あらゆるサービスのゲームのサーバも担当します。そのためたくさんの構築・運用・トラブルシュート・技術相談対応・技術評価実施と日夜向き合っています。インストールしたソフトウェアでなにか不具合があると、サービス側の開発スタッフさんらと一緒に解決策を練るのも良く行われます。ただ、不具合があっても、そのままシュバババっと解決して&俺強えぇぇーっ!というラノベばりの展開だと最高ですが、そんなわけないです。slack/zoomその他今時のリモートワークで人気のITツールを駆使して、落とし所を開発側スタッフさんと泥臭く探るということも多いです。とにかく問題を解決することが最優先なので、「高いハードルは、くぐってしまえ！」という解決策も大歓迎です!!今回は… pylint付属のpyreverseコマンドです。このツール、ご存じない方にお伝えするとpythonのプログラムのクラス相関図を自動で解析して図示するというツールです。人の書いたpythonを保守担当したりするとクラス相関の掌握がしやすくなるので、大変便利なツールです。$ sudo apt install pylint graphviz lsb-release xdot $ lsb_release -a No LSB modules are available. Distributor ID:Debian Description:Debian GNU/Linux 11 (bullseye) Release:11 Codename:bullseye $ pylint --version pylint 2.7.2 astroi

こんにちは、はじめまして。 スクウェア・エニックスのホシイと申します。この度わたしたちは、ここで、技術系のブログを公開できることになりました！制作に参加してくれてているパーティーメンバーをはじめ、ご理解・ご協力をいただいた皆様に感謝します。そして、さっそく読んでいただいているみなさま、ありがとうごさいます。このブログについて コロナ禍以来、以前のように物理的に集まるイベントが催される機会がぐっと減り、そういった場でのカジュアルな技術者同士のコミュニケーションの機会もまた少なくなってしまいました。ただいっぽうで、オンラインでのコミュニティやイベントが発達し、新しい方面での出会いが増えたりもしています。 そのようにして社外のかたとお話させていただく中で、スクエニの中でもいろんな人がいろんな仕事をしていることを、より広く知っていただけたらと思うことがありました。ゲーム開発に関する話題は注目を集めやすく、外部での発表も多くあります。そのいっぽうでスクエニ内では他にも多くの業務でたくさんの人が働いていて、ゲーム業界以外のエンジニアのかたともたくさんの共通点があります。ここではその隠れがちな面からもすこし発信をすることで、少しでも共感してもらえたらうれしいです。記事の内容は、(タイトルにも “ITエンジニア” と入っていますように) 巷でとにかく IT と名のつくものに触れる現場であればよく見られる、こまごました事柄を中心としたものになっていく予定です。 が、そのうちちょっと大きめのものや、すこし趣向を変えたものにもチャレンジしていけたらとも思っています。ここの記事が、すこしでもみなさまのお役に立ったり、息抜きになったりするとうれしいです。また、オンラインでもリアルでも、イベントの場などでお会いした際には、ここの話題でぜひお声かけいただけるとうれしいです！それでは、おたのしみください！