はじめに この記事を見つけたけど、後で見ようと思ったそこのあなた！ ぜひ下のボタンから、ハッシュタグ #ハマグリ式 でツイートしておきましょう！ こんにちハマグリ。貝藤らんまだぞ。 今回は番外編として、ハマグリ式！ 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) ) PRIMARY KEY (SingerId)' 参考 : gcloud spanner databases create | Google Cloud CLI Documentation

こんにちは 👋 ホシイです。 コロナウィルスによる感染はまだ続いている様子があるものの、自粛措置は落ち着き、対面の大規模な技術関連イベントも多く戻ってきました。 今回は、先日 8月3日 に福岡市で開催されました CloudNative Days Fukuoka 2023 に参加してきたレポートと、この機会を活用して福岡にある二社さまのオフィスを訪問させていただくことができましたので、その様子も合わせてお伝えいたします。 CloudNative Days Fukuoka 2023 こちらのイベントへの参加ははじめてで、クラウドネイティブの技術動向はもちろん、それが福岡の地域性とどのように合わさったものになるのかといった点に注目していました。 イベント会場は便利な場所にありじゅうぶんに広く、当日は暑い日でしたが開場早々から多くの参加者が訪れていました。オンラインでも参加が可能で、広いテーマで様々なセッションがありました。 各セッションでは地域性を活かした、現地のコミュニティや会社による発表、参加者の勢いが強く感じられました。 セッションの様子は公式サイトから オンライン視聴 も可能なようなので、気になるトピックがあれば見てみてください。 キーワードは他の技術カンファレンスでも取り上げられるものに似た様子ではありますが、より具体的な活用例が多く語られていた印象を持ちました。 展示ブースや自由に書けるホワイトボードが置かれたスペースもあり、セッションの合間に多くのかたにご挨拶ができました。思っていたより関東圏含め他の地域からの参加も多かったことに驚きましたが、開催地が違うことで、会話の前提が異なるのがおもしろいです。 (会場の様子がわかる写真をと思ったのですが、大勢が写っているものが多く省略させていただきます。ごめんなさい！) オフィス訪問 今回は事前に、普段からお世話になっている Google Cloud の企業ユーザー会である Jagu’e’r にて、訪問をお受け入れいただける先があるかお声かけさせていただきました。その結果ありがたく二社さまからお招きをいただき、お伺いすることができました。 それぞれについて、お話の内容とともにご紹介させていただきます。 ゼロバンク・デザインファクトリー株式会社さま (以下 ZDFさま) 銀行というイメージにとらわれないような新しい形態のサービスを展開されている同社、オフィスもそういった面をあらわすように、既存の銀行の建物を利用しつつも近代的でオシャレに改装された開放的なフロアになっていました。こちら ですこしその様子がわかります。 ミーティングにはオン・オフでたくさんの方に参加いただき、以下のようなお話を伺えました。 自己紹介 開発組織の体制・機能開発の流れについて 福岡と東京とにオフィスがあることによる分業のしかた 金融業界ならではの制約など 採用 他業界から入社されたかたも多く、既存のアイディアに縛られないオープンな考え方や広い範囲からの技術スタックの導入、スピード感が印象的でした。 クラスメソッド株式会社さま 技術ブログや AWS 技術支援で有名な同社、こちらもオン・オフ合わせてのご参加に加え、ZDFさまからもお一人ご参加いただきました。 こちらでは、以下のようなトピックが出ました。 自己紹介 資格取得やパブリッククラウド支援の取り組み 業界知識をどうつけていくか ブログ運営と社内の体制について クラウドデータベースの有効な活用 皆様さすがの資格取得の状況に圧倒されたところからはじまり、やはり技術の話はいくらでも盛り上がりそうでした。ブログ運営についても多く伺え、たいへん参考になりました。 オフィスの様子も見学させていただき、天気もよかった (ただしとても暑かった) ので大きな窓から博多の駅前がよく見えました。当日に出社されている方は多くありませんでしたが、やはり開放的で居心地がよさそうな空間になっていました。 訪問の記念に、クラスメソッドさまのオフィス入り口で集合写真を撮っていただきました。左から順にクラスメソッドさまの皆さん、弊社社員、ZDFさまからご参加いただいたお一人です。(Jagu’e’r 公式ポーズです 😆 )

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

今回は 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をセットする手間などが発生することになるのですが、自律構築の場合は反対にサーバ上で実行することと相性が良く問題とはなりません。 (再掲)適宜エンジニアが構築作業をするフロー テスト実行の概要 テストは以下のような図をコンセプトとして行われます。 gossのテストケースはyamlによって記述しますが、テストケースは以下の大きく２つの期待値をもとにサーバーの設定・状態をチェックする設計にしています。 metadataを通じて外部から動的に注入される設定値 Ansibleによってプロビジョニングされたプロセスやsystemd、サービスなどの状態 テストツールのファイル構成 gossのテストツールは以下のような配置で各サーバにapt installされるようになっています。 test-tool ├── bin │ ├── goss # gossバイナリファイル │ └── goss_test.sh # 実行時のwrapperスクリプト(後述) │ └── test_files # テストケースや動的な値(vars.yaml)を生成するディレクトリ │ # gossfile, varsfile ├── goss.yaml ├── vars.yaml │ # テストケースのファイル ├── mysql-common.yaml ├── mysql-master.

はじめに このページは以下の記事シリーズのうち、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:packer build base.pkr.hcl+ run:packer build mysql80.pkr.hclworking-directory:packer/sourceまた、set_env.shにより動的に生成されるイメージ名も以下の部分が差し替わった上でpacker buildが実行されるようになっています。 #!/bin/bash # source iamge名: base.pkr.hclで継続的にビルドされている共通ベースイメージの保存時のイメージ名がセットされる # base.pkr.hclでは"ubuntu-2004-focal-v20220308"がセットされていた箇所 echo PKR_VAR_source_image=custom-ubuntu2004-base-vYYYYMMDD-01 >> $GITHUB_ENV # カスタムイメージ名: MySQLのベースイメージ名として保存する名前をセット echo PKR_VAR_image_name=custom-ubuntu2004-mysql-vYYYYMMDD-01 >> $GITHUB_ENV # family名: MySQLのベースイメージのFamily名をセット echo PKR_VAR_image_family=custom-ubuntu2004-mysql >> $GITHUB_ENV MySQLベースイメージのプロビジョニング MySQLのプロビジョニングはmysql.

はじめに このページは以下の記事シリーズのうち、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を活用して運用しているものを今回のシリーズものの投稿で紹介したいと思います。 コンセプトの概要 自律的なサーバ構築を行う仕組みのコンセプトが以下の図のようになります。 先に書いたツライ部分を低減させるために以下の2点の課題解決に主眼をおいています。 構築できるまではサーバ側ですべて自律的にプロビジョニングが行われる 構築 → テストまでを行い、正常であれ異常であれ完了したら通知をする 先に白状しますと執筆時点では実装し本番環境でおおよそ動いてはいるものの、完全には自動化→通知という仕組みにはなっていません。このコンセプトに向かって実装しているということと、出来上がっている部分で参考にしていただける点が多くあると思うので、一読いただければ幸いです。 この記事の構成 この記事はこのページを含めて以下の4つに分かれています。 概要編(このページ) VMイメージ継続ビルド編 サーバ自律構築編 テスト編 長い記事構成になっていますが、VMの構築・運用が業務上必要で運用負担に悩むインフラに携わるエンジニアの方々の参考になると幸いです。

はじめに この記事を見つけたけど、後で見ようと思ったそこのあなた！ ぜひ下のボタンから、ハッシュタグ #ハマグリ式 でツイートしておきましょう！ こんにちハマグリ。貝藤らんまだぞ。 今回は 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 のディレクトリデザイン サンプルコード 構築のベストプラクティス 免責事項 この記事に書かれていることは弊社の意見を代表するものではありません。 この記事に書かれていることには一定の調査と検証を実施しておりますが、間違いが存在しうることはご承知おき下さい。 Terraform での transpose 関数の使いみち 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 Flavored Markdownをローカルでプレビューしたい で紹介したGitHub CLIも導入可能です。 "features": { "ghcr.io/devcontainers/features/github-cli:1": {} } また、GitHub CLIやGolangのランタイムのようなツールとは違う種類のfeatureとしてdocker-outside-of-docker を使うこともあります。 これは、devcontainer上から docker コマンドによるホストOS上のコンテナの操作を可能にします。

はじめに この記事を見つけたけど、後で見ようと思ったそこのあなた！ ぜひ下のボタンから、ハッシュタグ #ハマグリ式 でツイートしておきましょう！ こんにちハマグリ。貝藤らんまだぞ。 今回は 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 のディレクトリデザイン サンプルコード 構築のベストプラクティス 免責事項 この記事に書かれていることは弊社の意見を代表するものではありません。 この記事に書かれていることには一定の調査と検証を実施しておりますが、間違いが存在しうることはご承知おき下さい。 AWS で使う Terraform の落とし穴 Terraform が AWS リソース作成で非常に役立つ IaC ツールであることは、皆さんご存知かと思います。

皆さん、こんにちは！新卒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実行スレッドだけを止めています。 /* MySQL 5.7 */STOPSLAVESQL_THREAD;/* ~>MySQL 8.0.22 */STOPREPLICASQL_THREAD;今回は統合するデータベース単位でダンプを取ることにします。 mysqldump -h 'Replica DB1' -u 'DB1 User' -p --single-transaction --triggers --routines --set-gtid-purged=ON --databases DB1 > dump_DB1.sql mysqldump -h 'Replica DB2' -u 'DB2 User' -p --single-transaction --triggers --routines --set-gtid-purged=ON --databases DB2 > dump_DB2.

はじめに 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と、debugeeのhugo本体とデバッグ用シンボルファイルをDebianパッケージで導入します。 $ sudo apt install delve hugo hugo-dbgsym 次にDebianのhugoパッケージのソースコードデバッグをするのでソースコードを導入します。 $ mkdir hugo-src $ cd hugo-src $ apt-get source hugo ソースコードの位置はlsとpwdの結果どおり、/home/yours/hugo-src/hugo-0.111.3/になります。 $ ls hugo-0.111.3/ hugo_0.

シリーズ・すこしずつがんばる 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 でゼロトラストを実現するためのアプローチ ニコニコでのクラウド活用、その意思決定とアーキテクチャ はじめての機械学習ワークフローの作り方 〜データに集中したいあなたのために〜 ビジネスを支えるワークロードにおいてどのような課題を最適化するために NoSQL を活用するか これからの「動画」の話をしよう - 最新活用事例から見るメディア領域の進化と未来 セッション pickup 基調講演(今踏み出す、変革への一歩,アイデアを形にし、これまでにない価値を届ける) 基調講演では、全体の6~7割が事例紹介(各企業の方がゲストとして登壇)、残りがAWSの取り組みについてと新サービス(完全に新規というわけではなく、直近リリースされた注目サービスなど)についてでした。個人的には、AWSの今後の方針だったり新サービスの紹介などが中心なのかなと思っていたので少し意外でした。(どちらかというとAWS re:Inventがその役割に近そうですね)

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をちゃんと送ってるのに！ これが発生すると、とあるサービスが刺さってしまい、お客様にエラーが見えてしまうという問題が発生してしまうので、アプリケーション側でなんとかしたいというのが今回の相談です。再現率100%で発生であれば、アプリケーション側の挙動解析も容易なのですが、発生条件もよくわからず、ときおり発生するので、調査がままならないという状況です。 図のやりとりを100%いつでも発生できれば、アプリケーション側での対策を好きに調査と試行錯誤ができるのにぃ～。 やってみた この謎のパケットのやりとりを100%再現するプログラム(tcpchallenge_ack_only.py)を掲載します。プログラムの説明は後で掲載しますので、ここでは早速Debian sidで動かしてみます。 PyTCPを使うには、Linuxのセットアップ済のtapデバイスと、bridgeデバイスが必要ですので、まずはそこからセットアップします。 $ lsb_release -a No LSB modules are available. Distributor ID: Debian Description: Debian GNU/Linux 12 (bookworm) Release: 12 Codename: bookworm # tap デバイス(tap7)とブリッジ(br3)の準備 $ sudo apt install bridge-utils $ sudo ip tuntap add name tap7 mode tap $ sudo ip link set dev tap7 up $ sudo brctl addbr br3 $ sudo brctl addif br3 tap7 $ sudo ip address add 192.

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 してください。