メドピアのECSデプロイ方法の変遷 - メドピア開発者ブログ
CTO室SREの侘美です。好きなLinuxディストリビューションはLinux Mintです。 メドピアでは現在多数のサービスを運用しており、そのほとんどがAmazon ECSを構成の中核として利用しています。 ECSに対してデプロイを行う方法としては、CodeDeploy、CodePipeline、Copilot（ecs-cli）等があり、CloudFormationやTerraform等のIaCツールで何をどこまで管理するかも合わせて検討する必要があります。 どの方法にもメリット・デメリットがあり、Twitterや技術ブログを観測している範囲ではデファクトスタンダードと呼べる方法は未だに無いように思われます。 メドピアで最初にECSを利用し始めたのは2018年ころであり、これまで試行錯誤しながらECSのデプロイ方法とタスク定義の管理方法を模索してきました。 今回はメドピア社内で試してきた
なぜ WebAssembly 生成を Go にしたのか
オンラインイベントで聞かれて、ツイッターにつぶやいたら思った以上に反響があったので、もう少し詳細に書いてみます。 思ったより反響があったまとめ信頼できる暗号ライブラリがある自分が TypeScript より Go のほうが書けるGo の Wasm バイナリサイズを気にする必要がないWebCrypto にない暗号が必要自社の WebRTC SFU において End to End Encryption (E2EE) をブラウザ上で実現するためにはいくつかの壁がありました。 一つは WebCrypto が提供していない暗号を利用したいというものです。 今回 E2EE を実装するにあたり採用した Signal プロトコルでは公開鍵暗号に Curve25519 を採用しています。残念ながら WebCrypto では Curve25519 に対応していません。この時点で「暗号ライブラリをどこからもって
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
