監視ツールを迷ったら CloudWatch から始めてみるのもありなのでは - カミナシ エンジニアブログ
こんにちは、新規プロダクトの開発をしています、a2 （@A2hiro_tim ）です。 昨日、開発してきたプロダクトについて、正式リリースを発表させていただきました 🎉 prtimes.jp employee.kaminashi.jp さて、新規プロダクトの立ち上げは、技術選定や運用ツールの自由度が高く、どの監視ツールを使うか、選択に迷うこともあると思います。 我々のチームでは複数ツールの使用経験はあるものの、特定のツールの導入経験や深い知見があるメンバーはいなかったので、フラットに比較検討し、 Amazon CloudWatch の利用から始めてみよう、と意思決定しました。 主な選定理由は、 AWS エコシステムの中で完結できるため、Terraform Cloud などの既存の設定を流用できて新しく覚えることが少ない、AWS 上でコストを一元管理できる、等のメリットがある。 サービス開
円安を乗り越えるための Arm アーキテクチャへの移行が完了！ そのプロセスを公開します - カミナシ エンジニアブログ
こんにちは。ソフトウェアエンジニアの坂井 (@manabusakai) です。 カミナシでは、クラウドインフラストラクチャに AWS を採用していますが、昨今の円安を受けて円換算での請求額は右肩上がりで増え続けています。サービスの規模や特性に関わらず、パブリッククラウドを利用する多くの日本企業で頭痛の種になっているのではないでしょうか。 円安になる前から継続的にコスト最適化には取り組んできましたが、クイックウィンで実施できるものはやり尽くしており手詰まり感がありました。しかし、我々スタートアップにおいて適正なコストに抑えることはランウェイ（キャッシュ不足に陥るまでの残存期間）を伸ばす意味でも重要なため、現状に甘んじることなく次の最適化ポイントを探していました。 Arm アーキテクチャ移行によるコスト最適化への期待値 AWS は Arm ベースの Graviton プロセッサを開発しており、
はじめに UIを設計するときにオブジェクト指向UIは大きな効果を発揮することがあります。一方で、オブジェクト指向UIの考えをそのまま適用できないけれども、タスク指向UIと呼ぶのも微妙な画面があります。 例えば、ECサイトの購入プロセスです。よくあるECサイトの購入プロセスは以下の図のような構成です。これだけだと簡単そうですが、実際のECサイトの購入プロセスはある画面をスキップしたりしなかったりという制御があり、なかなかに複雑なものです。 今回の記事は画面遷移に順序があるがタスク指向UIと呼ぶのも微妙な、複雑な画面遷移を持つ画面にオブジェクト指向UIの考えを導入することで画面遷移制御を簡単にする手法を提案します。 対象読者 画面遷移の制御の保守性を向上させたいITエンジニア この記事の概要 複雑な画面遷移を持つUIに対して、オブジェクト指向UIの考え方を導入することで、制御フローをシンプルに
Terraformのmovedブロックやimportブロック、removedブロックは便利です。しかし、applyした後に削除するのが面倒です。面倒といっても何か制約がある訳ではなく、単に削除するPRを出すのが面倒という話です。そこまで頻繁にこれらのブロックを使うわけではないのですが、削除を楽にするために https://github.com/takaishi/tfclean というツールを作りました。 例えば、以下のようなtfファイルがあるとします。aws_security_groupリソースが1つと、movedブロックとimportブロック、removedブロックがあるファイルです。 resource "aws_security_group" "example" { name = "example-security-group" description = "Example secur
Repro では AWS 等のリソース管理に Terraform を活用しています。 この度 Terraform で管理しているコードの CI を Atlantis に移行したので、その経緯などについて書きます。 背景 Repro では以下のリソースを Terraform を使ってコード化して GitHub で管理しています。 AWS で構築したインフラ DataDog のモニターやアラート Google Cloud Platform で利用している一部のリソース GitHub の reproio organization のメンバーやチーム Kafka Topic MySQL アカウント PagerDuty の通知まわりの設定 Rollbar の通知 移行前は CircleCI や AWS CodeBuild を活用して独自に CI を構築していました。 課題 初期から CicleCI
SREの菅原です。 カンムのサービスはWebサービス・バッチ処理なども含めて基本的にはECS上で動かしているのですが、簡単なバッチ処理はLambda+EventBridge Schedulerの組み合わせで動かすこともあります。 LambdaはECSに比べてDockerイメージのビルドやECRの準備が不要で作成の手間が少ないのですが、terraformでデプロイまで含めて管理しようとすると少し問題がありました。 terraformでのLambdaのデプロイの問題点 例えば以下のような構成のNode.jsのLambdaをデプロイする場合 / ├── lambda.tf └── lambda ├── app.js ├── package-lock.json └── package.json // app.js const util = require("util"); const gis =
ECS Fargate の ARM64 版は長らくスポットが使えませんでしたが、ようやくやってきました。 利用するにあたって、いくつかポイントと注意点があるので、ザックリと把握しつつ自分用にどう構成するかを考えていく感じになると思います。 はじめに リリースや価格についてはこちらにまとまっています。 [アップデート] Fargate Spot で AWS Graviton ベースのコンピューティングがサポートされました | DevelopersIO 東京だとオンデマンドに比べて 62% OFF くらいです。前は Blue/Green の場合にスポットを利用できませんでしたが、今は解消されドキュメントからもその記述は消えています。 落ちやすさはまだわかりませんが、EC2 の例だと X86 より ARM64 の方が安定している雰囲気があるので、Fargate においても速い・安い・安定を期待で
CloudFormation 2024/08の更新（IaC ジェネレーターでのリソース検出とテンプレートレビューの機能強化） - Qiita
CloudFormation 2024/08の更新（IaC ジェネレーターでのリソース検出とテンプレートレビューの機能強化）AWSCloudFormation AWS CloudFormation IaCジェネレーターの更新 IaCジェネレーターで下記2つの機能が強化されました。 スキャンされたリソースの概要 表示 テンプレート表示にAWS Application Composerを利用（参照のみ） AWSの更新情報 What's New with AWS? では2024/8/22付で公開されました。 CloudFormation simplifies resource discovery and template review in the IaC Generator (CloudFormation IaCジェネレーターで リソース検出とテンプレートレビューを簡素化) 辞書として使えるC
2024 年 7 月と 8 月の AWS Black Belt オンラインセミナー資料及び動画公開のご案内 | Amazon Web Services
Amazon Web Services ブログ 2024 年 7 月と 8 月の AWS Black Belt オンラインセミナー資料及び動画公開のご案内 2024 年 7 月と 8 月に公開された AWS Black Belt オンラインセミナーの資料及び動画についてご案内させて頂きます。 動画はオンデマンドでご視聴いただけます。 また、過去の AWS Black Belt オンラインセミナーの資料及び動画は「AWS サービス別資料集」に一覧がございます。 YouTube の再生リストは「AWS Black Belt Online Seminar の Playlist」をご覧ください。 AWS Cost Anomaly Detection AWS Cost Anomaly Detection は、機械学習モデルを使用して、AWS サービスの異常な支出パターンを検出して警告する機能です。本
# https://aquasecurity.github.io/tfsec/v1.0.11/getting-started/configuration/github-actions/pr-commenter/ name: Run tfsec PR commenter run-name: tfsec PR commenter on: pull_request: types: [synchronize, opened] jobs: tfsec: runs-on: ubuntu-latest steps: - name: Clone repo uses: actions/checkout@master - name: Terraform security scan uses: tfsec/tfsec-pr-commenter-action@main with: github_token: ${
ConoHaとTerraformで始めるインフラ自動化 前編：導入から基本のサーバー構築まで / 開発者向けブログ・イベント | GMO Developers
本記事ではConoHa VPS Ver.3.0とTerraformを用いたインフラ管理の導入とシンプルなサーバーの構築方法を解説します。初めての方向けに環境構築や基礎的な設定手順を説明し、実際のサンプルコードを用いて進行します。 後編の「GPUサーバー構築と運用ガイド」も併せてご覧ください。 二部構成の本シリーズで、Terraformでのインフラ自動化を学ぶことができます。 1. はじめに：ConoHaとTerraformの強力な組み合わせ クラウドインフラの管理と自動化は、現代のITインフラの運用において非常に重要です。ConoHaは、日本国内で提供されているクラウドサービスの中でも、その使いやすさとコストパフォーマンスの高さから、多くのユーザーの皆様にご利用いただいております。 本記事では、ConoHa VPS Ver.3.0とTerraformを組み合わせることで、GPUサーバーを効
ConoHaとTerraformで始めるインフラ自動化 後編：GPUサーバー構築と運用ガイド / 開発者向けブログ・イベント | GMO Developers
本記事ではConoHa VPS Ver.3.0とTerraformを用いたインフラ管理の応用として、NVIDIA L4 GPU搭載GPUサーバーの構築方法を解説します。サンプルコードを使用し、具体的な手順に従って実用的なConoHaとTerraformの組み合わせ方を紹介します。 前編の「導入から基本のサーバー構築まで」もご確認ください。 1. 実践編：TerraformでNVIDIA L4 GPUサーバーを構築 ConoHa VPSでは記事執筆時点で「NVIDIA H100」や「NVIDIA L4」GPUを搭載した仮想サーバーを利用することができ、本セクションでは「NVIDIA L4」GPU搭載のサーバーをTerraformで構築します。価格や仕様などについては以下の公式サービスページを参照してください。 https://www.conoha.jp/vps/gpu/ 事前準備 GPU搭載
前書き 本記事の趣旨 完成イメージ図 本記事で取り扱わないこと 対象読者 デプロイ用のCDK作成 フロントエンドのプロジェクト作成 バックエンドのプロジェクト作成 Dockerfileの編集 app.pyの編集 requirements.txtの編集 AWSのインフラ部分の作成 CDKのデプロイ デプロイ後のリソースの確認 サービス 作成順序について ECSのコンテナ同士の通信関係の表現 バックエンドコンテナの名前解決はどうなっているか？ マネジメントコンソールから動作を確認する 負荷をかけて、挙動を確かめてみる。 まとめ 前書き CS1の石井です。 直近の案件でECSを使う構成を検討しており、ECSについて調査していました。 調査中に「Service Connectという設定が、いい感じにサービス同士の通信をやってくれる」という話を聞いて、実際に試して挙動を確認してみたいなぁと思いました
最近は関わる案件の多くで IaC を前提とすることが多くなってきました。 Azure においては、主に Terraform と Bicep という選択肢があると思うのですが、改めて自分なりにどちらを使うと良さそうか考えてみたので、残しておこうと思います。 1. それぞれのメリット／デメリット 「👍️」は特に良いと感じる点、「🤯」は特に辛いと感じる点です。 Terraform のメリット 👍️マルチクラウド対応: Azure だけでなく、AWS, GCP などのクラウドプロバイダに対応しているため、異なるクラウド環境で一貫した管理が可能。 大規模なエコシステム: Terraform には多くのプロバイダとモジュールが存在し、広範なコミュニティサポートがある。 成熟したツール: 長く利用されているため、ドキュメントが充実しており、企業での導入事例やベストプラクティスも多い。 プランニング
![[Azure] Terraform or Bicep を考えてみた](https://cdn-ak-scissors.b.st-hatena.com/image/square/caa0901393250dd2a7c2006b43d5bcb2714d3181/height=288;version=1;width=512/https%3A%2F%2Fres.cloudinary.com%2Fzenn%2Fimage%2Fupload%2Fs--938UZdtc--%2Fc_fit%252Cg_north_west%252Cl_text%3Anotosansjp-medium.otf_55%3A%25255BAzure%25255D%252520Terraform%252520or%252520Bicep%252520%2525E3%252582%252592%2525E8%252580%252583%2525E3%252581%252588%2525E3%252581%2525A6%2525E3%252581%2525BF%2525E3%252581%25259F%252Cw_1010%252Cx_90%252Cy_100%2Fg_south_west%252Cl_text%3Anotosansjp-medium.otf_37%3Asou%252520%25252808thse%252529%252Cx_203%252Cy_121%2Fg_south_west%252Ch_90%252Cl_fetch%3AaHR0cHM6Ly9zdG9yYWdlLmdvb2dsZWFwaXMuY29tL3plbm4tdXNlci11cGxvYWQvYXZhdGFyLzhkOTllYzIxMjUuanBlZw%3D%3D%252Cr_max%252Cw_90%252Cx_87%252Cy_95%2Fv1627283836%2Fdefault%2Fog-base-w1200-v2.png)
[アップデート] Fargate Spot で AWS Graviton ベースのコンピューティングがサポートされました | DevelopersIO
こんにちは、中川です。 Fargate Spot で AWS Graviton ベースのコンピューティングがサポートされました。 Fargate Spot は通常の Fargate（オンデマンド）と比較して、最大 70% 割引価格で利用できる購入オプションです。 これまでは、Fargate Spot で x86 ベースの CPU アーキテクチャのみサポートされていました。 今回のアップデートにより、AWS Graviton ベースのコンピューティングでも Fargate Spot が利用可能になり、ARM アーキテクチャを利用したアプリケーションでも大幅な割引オプションを利用できるようになりました。 料金 ARM ベースの通常 Fargate、x86 ベースの Fargate Spot と東京リージョンで料金を比較した表が以下になります。 CPU キャパシティプロバイダ 時間あたりの vC
![[アップデート] Fargate Spot で AWS Graviton ベースのコンピューティングがサポートされました | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/f148243ac02b0fa489580e33beff23e44b600723/height=288;version=1;width=512/https%3A%2F%2Fimages.ctfassets.net%2Fct0aopd36mqt%2Fwp-thumbnail-c1b708083968781e5e6f8e97b66f63e9%2Fa49e000e77ecc72d1e98e65a083c2da8%2Faws-fargate)
primeNumberのSWEの中根 (@gtnao) です。 先月、TROCCO®︎のTerraform Provider(β版)をリリースしました。 今回は、その経緯や開発の流れについて共有したいと思います。 TROCCO® の Terraform Provider(β版) がリリースされました！https://t.co/QDLPz9qkXe ・データマート定義をTerraformで管理可能（作成、変更、削除） ・転送設定、ワークフロー、などもサポート検討中 ※APIオプションの契約が必要です ぜひお試しいただき、フィードバックいただければと思います！ — kekekenta | TROCCO® | CTO@primeNumber (@kekekenta) August 9, 2024 Who are you6年前(2018年11月)にprimeNumberにジョイン。 TROCCO®
Terraform と Bicep の比較
統合機能 操作性機能 スケールを実現するために、DevOps チームは常に信頼された反復可能なプロセスを使用してコードをすばやくデプロイする方法を探しています。 クラウドとインフラストラクチャに関しては、コードとしてのインフラストラクチャ (IaC) でこのプロセスの実現が加速しています。 IaC ツールには、特定の環境向けのさまざまな汎用ツールがあります。 Terraform は前者の一例です。一方、Bicep は Azure 関連のタスクを処理するように設計されています。 この記事では、Bicep と Terraform の 9 つのインフラストラクチャおよび統合機能を比較します。 これらの違いを理解すると、インフラストラクチャとプロセスをサポートするのに最適なツールを決めるのに役立ちます。 状態とバックエンド Terraform と Bicep はどちらも Desired State
GitHub Actionsとtfcmtのみで実現する、atlantis風のterraform workflow - decadence
これは何 Atlantis を利用すると、PullRequestを利用したterraform実行環境として以下のようなWorkflowが実現出来る。 terraform の変更を含む PR を作成 PR上でplanをコメントで表示 atlantis apply のコメントをPRにすることでterraform applyを実施して、コメントで表示 とはいえatlantisはサーバを立てる必要もあるし、GitHub Actionsのみで簡易的なものを実現してみた事例が、今回述べたいこと。 今回実現したこと 以下のことを実現している PRでterraform planの結果を表示 PRにコメントをすることで、terraform applyを実施して、結果をコメントに表示 一方で、atlantisで出来るような以下のことについては対応していない。 plan結果をもとにしたapply実施 appro
ECS(Fargate)上に構築したLocustからAPIサーバ(Go)経由で、TiDB Cloudにクエリを実行してみた | DevelopersIO
package main import ( "database/sql" "log" "net/http" "crypto/tls" "github.com/go-sql-driver/mysql" ) // 起動するポート const port = "8080" func helloHandler(w http.ResponseWriter, r *http.Request) { // データベース接続 // TiDB Cloudにて表示されたコード mysql.RegisterTLSConfig("tidb", &tls.Config{ MinVersion: tls.VersionTLS12, ServerName: "gateway01.ap-northeast-1.prod.aws.tidbcloud.com", }) db, err := sql.Open("mysql", "
こんにちは、SREグループの水戸 (@y_310)です。Terraformを継続的に使用していると、時々一括して大量のファイルの記法を修正したくなる時があります。 単純な置換であればsedで十分ですが、少し複雑な変換になるとsedでは難しいこともあります。そんな時はHCLの公式リポジトリに含まれているhclwriteパッケージを使うとHCLを構文解析した上で参照編集できるので便利なのですが、hclwriteはあくまでGo言語のライブラリなので使用にはGoでの実装が必要になります。この記事では気軽にtfファイルを編集できるようにhclwriteの簡単な使い方を紹介したいと思います。 tfファイルを開いて、formatして保存する まずはこの後の実装の下準備として、基本構造となるファイルを開いて保存する、という処理を実装します。ついでにterraform fmt相当のformat処理もします。
Terraformの環境の分離について考えてみる
はじめに インフラチームのkuribo-です。 今回はTerraformのコードを管理する上でどのようなディレクトリ構成にすれば良いかを考えまとめてみました。 Terraformって何？ 簡単にTerraformの説明です。 TerraformとはHashiCorp社が提供する、IaC（Infrastructure as Code）のツールです。 HCL（HashiCorp Configuration Language）という言語でインフラ構成を記述していきます。 特定のクラウドプロバイダーに依存したツールではなく、利用するクラウドをProviderとしてHCLで宣言することで利用ができます。 Terraformを使うメリットは以下の通りです。 インフラをコードとして記述できるのでレビューができるようになります。 コードで記述するのでコードを読むことでインフラ構成がわかります。 コードを別
ECS(Fargate)上にLocustとAPIサーバ(Go)を構築してService Connectで接続してみた | DevelopersIO
こんにちは、ゲームソリューション部のsoraです。 今回は、ECS(Fargate)上にLocustとAPIサーバ(Go)を構築してService Connectで接続してみたことについて書いていきます。 イメージの作成 LocustとLocustのリクエスト先のAPIサーバのイメージを作成します。 Locust Locustのdockerfileは以下です。 FROM locustio/locust WORKDIR /locust # Locustのシナリオファイルを配置 COPY locustfile.py /locust/locustfile.py # Locustのシナリオを実行 CMD ["-f", "/locust/locustfile.py"]
はじめに terraformには実行時のログを、TRACE・DEBUG・INFO・WARN・ERRORと指定することが出来ます。どのレベルでどういった内容のログが出力されるかを試してみようと思います。 出力方法 ec2を作成するのみの簡単なtfファイルをapplyし、その時のログを確認してみようと思います。
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
画面遷移に順序があるUIの保守性を向上させる「順序ありオブジェクト指向UI」の提案
Terraformで不要になったmoved/import/removedブロックを楽に削除する
TerraformのCIをAtlantisに移行しました - Repro Tech Blog
terrraformを使ったGoのLambdaの管理 - カンムテックブログ
AWS ECS ARM64 FARGATE_SPOT 利用上のポイント | 外道父の匠
Github Actions で見る tfsec と Trivy の今 ~ Terraform 静的解析
ECSのService Connectを試す記事 - サーバーワークスエンジニアブログ
[Azure] Terraform or Bicep を考えてみた
TROCCO®︎のTerraform Providerを企画からリリース、周知まで3週間で行った話｜gtnao
hclwriteを使ってtfファイルを編集する - GO Tech Blog
terraformのログを出力してみる - Qiita