AWS の資格勉強をしていて、ディスクの性能が全然違ったので自分なりに整理しました。 Azure Managed Disk の個人的なイメージ Standard HDD、Standard SSD、Premium SSD が基本的な選択肢 Standard SSD と Standard HDD は性能差がそこまで大きくない（IOPS は同じでバーストできる程度） Premium SSD を選択すると、利用可能な IOPS が爆増する Amazon EBS との比較 対応関係は乱暴に言うと下記のようになります。 Standard HDD = st1 Standard SSD = gp3 Premium SSD = io2 Azure の場合、ディスク容量が 4,096GiB 以下とそれより上で性能の値が全く異なってくるため、下記は 4,096GiB 以下の容量での比較で記載します。 Standard HDD と st1 の性能差 スループットに関して、Standard HDD の場合 60MB/秒 で固定値であるのに対し、st1 の場合は TiB ごとに 40 MiB/秒となっているので、容量に比例したスループットを得られます。 IOPS はどちらも 500。 また AWS の方はアクセス頻度の低いアーカイブ用の sc1 という HDD のディスクがあります。...

概要 AWS の理解向上を兼ねて、CloudFront で S3 上の HTML を配信する構成のサンプルを terraform で構成してみました。 AWS Certificate Manager (ACM) で証明書を発行し、CloudFront に割り当てて、カスタムドメインで配信します。 実際のソース 下記に配置しています。 https://github.com/hirokimatsueda/aws-cf-s3-terraform-sample 実行時の前提 CloudFront に割り当てる親ドメインを管理する DNS 名前解決が可能な Route 53 がすでに構築されていること 実装ポイント CloudFront の制約上、ACM を us-east-1 に構築する必要があるため、コードの簡素化のため全てのリソースを us-east-1 に構築しています provider "aws" { region = "us-east-1"# CloudFront用のACMの要件に沿って設定 access_key = var.aws_access_key secret_key = var.aws_secret_key } S3 は CloudFront 以外からパブリックなアクセスをさせたくないため、IAM ポリシーを使用して CloudFront のみからアクセス可能にしています data "aws_iam_policy_document" "static_site" { statement { sid = "AllowCloudFront" effect = "Allow" principals { type = "AWS" identifiers = [ var....

概要 Azure にも AWS にもマネージドな Kubernetes があり、それぞれ Azure Kubernetes Service (AKS) と Amazon Elastic Kubernetes Service (EKS) という名前です。 AKS（に限らず Azure のサービス）は、Azure ポータルから構築を進めるとすぐに使えることが多いです。 EKS も AKS と同じノリでポータルで構築したらなかなか動かなかったので、ハマったポイントを共有します。 ノードグループを追加しないと動かない Kubernetes はワーカーノードが無いと Pod を動かすことができません。 AKS の場合、ワーカーノードを動かすためにはノードプールを用意する必要があります。 Azure ポータルから AKS クラスタを構築するときはノードプールの作成がデフォルトで指定されており、更にノードプール（厳密にはシステムモードのノードプール）の作成を指定していないとそもそも AKS 自体を構築できません。 これに対して EKS の場合は、AWS コンソールから EKS クラスタを作成しただけではワーカーノードを動かすために必要なノードグループを作成してくれません。 クラスタはできているので、EKS に対してマニフェストファイルを apply する分には実行できるのですが、待っていても永遠に Pod が立ち上がりません。 永続ボリュームとしての EBS のマウントにはアドオンを追加する必要がある AKS の場合、永続ボリュームとしてマネージドディスクをマウントする場合、StorageClass や Persistent Volume Claim のマニフェストファイルを用意していけば使えるのでアドオンを意識することはありませんでした。 クラスタの構築時も特にアドオンの選択はさせられません。 EKS の場合は、クラスタの構築後にアドオンで EBS CSI driver を追加しないと EBS を永続ボリュームとして利用できません。...

皆さんはパブリックに公開したシステムの正常稼働をどのように監視していますか？ 私は趣味でレンタルサーバーを常時動かしているのですが、HTTP 監視を行い不具合の検出をすぐに行えるようにしています。 監視には Azure の Application Insights を利用しており、利用料金も私の使い方であれば格安ですので、こちらをご紹介したいと思います。 HTTP 監視とは？ HTTP 監視とは、監視対象に対して定期的に HTTP のリクエストを送信し、その応答（200 応答するか？など）を確認する監視方法です。 サーバー内部の不具合までは見られませんが、サーバーが落ちていないなど、ある程度の正常稼働を認識することができます。 Application Insights による HTTP 監視 Azure の Application Insights を利用すると、お手軽に HTTP 監視を構成できます。 可用性テストという名称です。 Application Insights を構築し、Azure ポータルから「可用性」の画面を開くと設定を追加できます。 「クラシックテスト」と「標準テスト」が存在しますが、「標準テスト」で実現することになります。 （Azure で「クラシック」と名の付くものは廃止されていく運命にあることが多いです） 標準テストのドキュメントに沿って設定してみましょう。 Application Insights の構築・設定時のポイント Application Insights の構築時に 2023/08/19 現在は「リソース モード」の選択がありますが、「クラシック」ではなく「ワークスペースベース」を選択します。クラシックは廃止予定の構成です。 URL にはポート番号の指定も可能ですので、通常のポート（HTTPS なら 443 とか）以外に対してもテストできます 東日本リージョンの Application Insights の場合、テスト 1 回につき $0.0008 のコストなので、要件に合わせて「テストの頻度」と「テストの場所」の数を調整しましょう 警告を「有効」にして追加の設定を入れ込むことで、HTTP 応答に問題があった際にメール通知等ができます 趣味程度の使い方の場合の料金は？ 趣味程度のサーバーなので、テストの頻度を 15 分毎、テストの場所を Japan East にしていますが、1 日当たり 8....

皆さん、Azure の Premium なオプションはどれくらい使えていますか？ 私は WebApps と SQL Database がぱっと頭に浮かびますが、よく考えるといろいろありますよね。 Microsoft Learn を参考に、ストレージアカウントの選択可能なオプションを覚えるため整理してみたいと思います。 ストレージ アカウントの種類 https://learn.microsoft.com/ja-jp/training/modules/design-data-storage-solution-for-non-relational-data/3-design-for-azure-storage-accounts Azure ポータルからデフォルト設定で構築していくと、「Standard 汎用 v2」が選択されると思います。 こちらを使えば、よくある Web サイト等を動かすには十分な性能のものが利用でき、安価にデータを保管できます。 必要に応じて CDN などの他のサービスも組み合わせますかね。 これに対し、「Standard 汎用 v2」以外には下記の Premium なオプションがあります。 Premium ブロック BLOB Premium ファイル共有 Premium ページ BLOB 「Standard 汎用 v2」の場合、Blob Storage (Data Lake Storage を含む)、Queue Storage、Table Storage、Azure Files の 4 つのサービスが提供されますが、上記の Premium なオプションを利用した場合は特定のサービスにサポートが限定されます。 各オプションについて、高いスループット以外のドキュメント上で気になるところをピックアップしていきます。 （2023/7/28 時点のドキュメントからピックアップ） Premium ブロック BLOB 高速の一貫した応答時間を要するワークロードや、小さな読み書きが大量に行われるワークロードに適している コスト効率で言うと、トランザクションコストが低く設定されており、使用方法によっては「Standard 汎用 v2」よりも安くなる場合も考えられる Premium ファイル共有 サーバー メッセージ ブロック (SMB) と NFS ファイル共有の両方をサポートする必要がある場合に利用 最大同時要求レートは 100,000 IOPS で、Standard の 20,000 IOPS よりはるかに高い ストレージアカウントの最大容量は(100TiB)で、Standard の 5PiB より小さい Premium ページ BLOB BLOB あたり最大 7,500 IOPS と 250MBps のプロビジョニングされたディスク パフォーマンスを提供 サイズは固定で最大 8TB 補足：Blob のアクセス層 https://learn....

はじめに GitOps は、開発者がコードを Git リポジトリにプッシュすることで自動的にインフラストラクチャーが更新される仕組みです。 Flux は、GitOps を実現するためのツールであり、Kubernetes の manifest ファイルを Git リポジトリに保存し、変更があるたびに自動でデプロイすることができます。 本記事では、Terraform を用いて AKS 上に Flux を導入する手順を説明し、GitOps のデモを行います。 AKS 上に Flux を導入する手順 連携先の GitHub リポジトリの準備 GitHub リポジトリが空だと Terraform の実行時にエラーになるため、main ブランチに readme か何かを入れておいてください。 続いて GitHub との認証情報の準備です。 今回は Deploy key を用いて Flux から GitHub に接続する方針で説明します。 Deploy key の作成方法は下記です。 接続に使用する SSH キーを生成します 参考：https://docs.github.com/ja/authentication/connecting-to-github-with-ssh/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent#generating-a-new-ssh-key 対象のリポジトリの「Setting」から、「Deploy keys」を開きます 「Add deploy key」をクリックします Title に任意の名称を設定し、SSH キーの公開鍵をコピペし、「Allow write access」のチェックを入れて「Add key」します SSH キーの秘密鍵は Terraform の実行時に必要になります。...

社内で爆発的に流行っている ChatGPT に手を出したら、とてもハマってしまいました。 信長の野望以来のマイブーム？ 隙間時間に無理難題を問いかけて、反応を楽しんでいます。 問いかけに対してうまく答えたり答えなかったりするところが、何となく子育てに近い感じがします。 ちょっとお遊びですが、子供向けの曲を作ってもらおうとしてみました。 まずは作詞！ すごくアバウトに振ってみましょう。 架空の子供番組の歌を作って ↓ lyrics 1 それっぽい！？ 最後の歌詞を見る限りは、オープニング曲というよりエンディング曲ですかね？ コード進行は作れるか？ 続いて曲にするためにコード進行を決めていきましょう。 良いね！ コード進行を教えて ↓ chord progression 1 う～ん・・・流石にこれは詰まらなすぎます。 ちょっとつまらないので、ヴァースで変化をつけて ↓ chord progression 2 (ヴァースじゃなくてコーラスで変化を付けさせるべきだった気も・・・) いやぁ・・・これもちょっとなぁ。 私の好きな、某イスが主役の番組の音楽とか想像すると物足りないです。 最近の子供番組はもっと複雑な進行になる印象です。 もう少し思い切った形になりますか？ ↓ chord progression 3 ちょっとやり過ぎな感じもしますが、良しとしますか！ コードに合わせて歌詞を調整 ブリッジが追加されて歌詞との対応関係が崩れたようなので、歌詞を調整してみます。 良いですね、このコードに沿って歌の歌詞を調整してください。 ↓ lyrics 2 lyrics 2 やはりエンディング曲な締めですが、弾き語りで使えそうなメモになってきました。 メロディーラインも作れるか？ ここまで来たらメロディーラインも作ってほしいですね。 メロディラインを作ってください ↓ melody 1 途中で回答の生成を止めちゃいましたが、音楽の生成をやろうとしてたので、文字で再度書いてもらうことに。...

Kubernetes はマニフェストファイルを用いて状態を定義することで、思い描く環境を作ることができるのが便利ですよね。 ただ、ある一定の前提を満たさないと状態が定義できない時があります。 例えば namespace が事前に存在していないと、その名前空間にはリソースが作れません。 namespace の場合は kubectl create namespace を実行してからほかの作業を実施するような順次実行をすることで解決できますね。 これで解決しないとき、例えば Kubernetes Operator のインストール完了を待機したい場合はどうすると良いでしょうか？ kubectl wait で作業完了を待機 kubectl wait というコマンドがあります。 https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#wait このコマンドは、リソースの状態が指定した状態になるのを待機してくれます。 分かりやすい話だと例えば、deployment が available になるのを待機するには下記のように記載します。 kubectl wait --timeout=90s --for=condition=available deployment/name-of-deployment timeout の指定により、90 秒以内に状態が変わらなければ諦めます。 こちらは deployment 以外にも適用できるようで、Kubernetes Operator のインストールに使われる installplan が installed になるのを待機するにはこんな風に書けば良さそうです。 kubectl wait --timeout=90s --for=condition=installed installplan/name-of-installplan -n operators このあたりを組み合わせれば、Kubernetes Operator のインストール処理の完了を待機して後続処理を実装することができそうですね。 まとめ 短いですが、さまざまなリソースの状態を待機できる kubectl wait についてご紹介してみました。 特に初期セットアップの自動化に役立つコマンドなのではないでしょうか？

※ この記事は、cloud.config Tech Blog にもマルチポストする予定です 子供が産まれて妻子の入院期間中、体温や授乳回数やおしっこ・うんちの時間を記録する紙があって、そこに毎日記録していました。 退院後もそのフォーマットを Excel で真似て紙に印刷して使っていて、子供の不調が無いか確認していました。 子供が 1 歳になった今も一応、記録内容を減らした紙を運用してはいるものの、ほとんど問題ないのであまり書いていないです。 ただその中で、絶対書いておきたいのが、 うんちの記録です！ 便秘だと不機嫌になったり場合によっては病院に行かないといけなくなります。 うちの子は最近は割と快便ですが、最初の頃は便秘でとても心配しました。 また、うんちがあまり出ていない状態でお風呂に入ると・・・ね。。 ということで、うんちの回数を記録するアプリを書いてみましたのでご紹介です。 Screen shot アプリの概要 カレンダーの中の「＋」ボタンを押すと、当日の枠に 💩 マークがつきます。 データは Cosmos DB に保管されます。 アプリコード Visual Studio 2022 で作成しました。GitHub で見れるようにしています。 https://github.com/hirokimatsueda/baby-info-recording-system フロントアプリの実装は大目に見てください。。 フロントの作りが微妙ですが・・・赤ちゃん ID を変更すると別々のデータを管理できるので、双子や兄弟のデータも扱えます。 アーキテクチャ概要 インフラとしては Azure の Static Web Apps での動作を想定し、情報を CosmosDB に保存するので、比較的安価に運用できるものになっています。 アプリは ASP.NET Core Blazor での記述です。 インフラもアプリも、ベースとなる考え方は以前ブログでご紹介した下記のコードです。 https://github.com/hirokimatsueda/azure-managed-id-sample インフラ構築 Api は Static Web Apps のデフォルトの機能で動かすと Managed ID が使えないため、Static Web Apps とは別で構築した Functions を Static Web Apps にリンクする形を取るのがポイントです。...