Introduction はじめまして、SRE G の渡邉です。今回のブログでは、以前の弊社 VP of Engineering佐藤によるコインチェックでの DX Criteria の活用 https://tech.coincheck.blog/entry/2021/12/13/115048 にあった「SLI/SLO/エラーバジェットの決定」の話をします。 コインチェックでは、策定にあたってこんなことを考えて、こんな 感じのものを策定した、を紹介しますので、皆様のSLO策定・改善の役に立てていただけると幸いです 策定の経緯 SREとしてトイル削減やアラート整理などは進めていたのですが、それがある程度落ち着いてきてからは、SLOの策定はやらないといけないとは思いつつもその必要性から説明をしてつくっていくのは相当なパワーを使うのでなかなか手を付けられていませんでした。 それが、2020年の末あ
お知らせ 2022年初頭に本記事を元にしたAWS書籍が技術評論社より全国出版決定いたしました。 関係者各位のご協力に深く感謝いたします。 タイトル：AWSエンジニア入門講座――学習ロードマップで体系的に学ぶ 本書籍出版までの制作プロセス、チーム執筆の方法論などをまとめました チームで技術書を出版して学べた共同執筆メソッド はじめに インフラ初学者がAWSを用いた設計・構築レベルに到達するため、学習の全体像をロードマップ図にまとめました。 背景 パブリッククラウド全盛期においてAWSは全エンジニアにとって「常識」となりました。 しかしながら、情報過多によってAWS学習に必要な情報がネット上のノイズに埋もれてしまい、初学者の直感による判断が誤った学習に行き着くこともあります。 このロードマップはAWS学習の全体像を俯瞰でき、パブリッククラウドを用いた設計・構築レベルに到達するまで導く体系的なス
はじめにこんにちは、Finatext で保険事業にてプロダクト開発をしている @toshipon です。今回は我々のプロダクトでも活用している AWS Amplify コンソールにおける Custom headers の運用についてお話いたします。 概要Amplify 上で Custom headers を設定する手順についてご紹介いたします。Custom headers は、HTTP レスポンスのヘッダーに指定できる情報を管理するもので、主にデバッグやセキュリティ対策、情報提供に利用されます。 今回は、キャッシュを適切に有効にさせてパフォーマンスを向上させたり、XSSやクリックジャッキング等のWebアプリケーション脆弱性に対処することを目的として利用したいと思います。 また、Content-Security-Policy-Report-Only というセキュリティヘッダー（説明については
はじめにこんにちは、Finatext で保険事業のプロダクト開発をしている @toshipon です。今回は我々の一部の現場で取り組んでいる、ECS Fargate 上で利用する環境変数を、 S3 bucket を使って運用しているお話を紹介いたします。 概要ECS Fargate 上で、アプリケーションコードと同期的に環境変数の更新を行いたい。 そのために、mozilla/sops というファイル暗号化ツールを利用して暗号化した環境変数ファイルをアプリケーションコードのリポジトリで管理し、CI/CD ( Codepipeline ) によるデプロイのタイミングで、環境変数ファイルを復号してS3にアップロードし、ECS task上で S3 から環境変数を参照する仕組みを紹介いたします。 解決したい課題環境変数更新とアプリケーションコードデプロイのタイミングが非同期であることECS Farg
Lapper is a wrapper programs for Container running on Lambda. (Beta) - Finatext/lapper AWS Lambdaのエラー通知どうするか問題Finatextでは、サーバレスなタスク実行の基盤として、AWS Lambdaを活用しています。 具体的なユースケースとしては、 CloudWatch EventsのSchedule expressionsをトリガーにした、定時処理SQSやS3のEvent NotificationやCloudWatch Eventsの特定のイベントをトリガーに起動する、非定時処理API Gateway等を介したHTTPSリクエストをトリガーにした、Webサーバとしての処理あたりがあります。 Lambdaを使うことによる恩恵はあらためて言及するまでもないと思いますが、非常に便利に使っています
こんにちは、崔です。 今回は、2020年9月8日から9月30日の間で開催されているAWS Summit Online のセッションで「金融の再発明を可能にするセキュリティとアジリティ ～ Finatext グループでの AWS 活用事例 ～」を視聴しましたので、レポートをお届けします。 ミッションクリティカルな金融サービスにおいて、AWSを利活用することで、アジリティとセキュリティを改善されていました。 セッション情報 スピーカー 株式会社 Finatext ホールディングス 代表取締役 林 良太 氏 リードエンジニア 田島 悟史 氏 概要 Finatext グループは、「金融を“サービス”として再発明する」をミッションに掲げています。 レガシーシステムが多く残る金融業界において、金融サービスに共通して必要となる機能をクラウド化し、サービス設計から開発、グロース施策までを一気通貫で提供する
監視・通知の仕組みの全体像また、弊社では Terraform を用いて IaC ( Infrastructure as Code ) を実現して、各AWSアカウント環境の状態をコードで一元管理していますが、 Datadog の監視項目も Provider が用意されているため、Terraform で管理をすることが可能です。現状はすべての Datadog の監視項目がコード化されているわけではないですが、こちらは随時対応を行っていきたいと思っています。 外形監視外形監視は、WebサイトやAPIエンドポイントが正常に動作していることを、定期的に特定のURLに対して問い合わせをして、期待されたステータスコードや要素を返すことを監視することを目的とします。 弊社では Datadog の Synthetic Monitoring という機能を利用して監視を行っていますが、この機能の特徴としては W
はじめに 先日、僕が担当する業務でECS/Fargate利用を前提にDevSecOpsアーキテクチャをデザインし、社内のAWS勉強会にて登壇する機会をいただきました。 本ブログでも内容をかいつまんでご紹介できればと思います。 AWSによらず、コンテナを利用されている方にとって、一つのプラクティス例としてご参考になれば幸いです。 ※コンテナ自体の説明や必要性に関する内容は省略していますm(_ _)m そもそもDevOpsとは？ DevSecOpsの導入意義をお伝えするた前に、まず軽くDevOpsの意義をお伝えします。 ※とは言え、この記事をご訪問されている方にとっては「何をいまさら...」な内容かもしれませんし、ググればDevOps自体の情報はたくさん見つかりますので、重要なポイントのみ述べることにします。 DevOpsとは、一言で述べれば、開発チームと運用チームが協力してビジネス価値を高め
AWS News Blog New – Local Mocking and Testing with the Amplify CLI The open source Amplify Framework provides a set of libraries, user interface (UI) components, and a command line interface (CLI) that make it easier to add sophisticated cloud features to your web or mobile apps by provisioning backend resources using AWS CloudFormation. A comment I often get when talking with our customers, is th
Amazon Web Services ブログ 詳細: Fargate データプレーン 本日、AWS Fargate の新しいプラットフォームバージョン (1.4) をリリースしました。これには、お客様のための数多くの新しい機能が含まれています。これらの機能の詳細については、こちらのブログ記事をご覧ください。プラットフォームバージョン 1.4 で導入された変更点の 1 つは、Fargate のコンテナ実行エンジンとして、Docker Engine を Containerd に置き換えたことです。 このブログ記事では、お客様のコンテナのワークロードにとってこれが何を意味するか、この変更の背後にある動機、およびこの再設計されたコンテナ実行環境 (Fargate データプレーンとも呼ばれます) の内情について詳しく説明します。 用語集 ブログの本編で使用する用語と概念を確認してみましょう。 コ
お疲れさまです！フクロウラボ若杉です。 ほんと、時間が過ぎるのが早いですね〜。この1,2年はそうなんですが、一方で、プライベートでも様変わりしているせいか、1年前が3,4年位前のような感じもしている今日このごろです。 さて、前回は、 AWS AppSyncでGraphQL【実践編その１（Vue＋Amplify＋Cognito）】 ということで、Amplifyを使ってメモアプリを作成しました。 今回は、GraphQLのSubscriptionを使ってサーバープッシュなアプリを作ってみようと思います。 前回作ったメモアプリ�を改良して作ろうかと思ったのですが、そもそもメモアプリはCognitoでの認証が入って本人しか見られないコンテンツなため、今回のサンプルにはマッチしなさそうだったので、ゼロから普通の掲示板を作って、更新したタイミングで他に閲覧しているユーザーへもリアルタイムに更新をかけると
Talking about serverless architecture goes way beyond Function as a Service (FaaS) like AWS Lambdas. Two of the reasons why Lambdas are so attractive are their auto-scale (in & out) capability and their pay-per-use pricing model. In order to leverage these capabilities and reach the full benefits of a serverless architecture, we need our other infrastructure components to have the same flexibility
AWS においてはマルチアカウント戦略が重要とされています。 たとえば、開発環境/ステージング環境/本番環境といった各環境は、セキュリティ、ガバナンス面で分離すべきです。 メンバーの権限管理がすっきりする 特定の環境の作業が他環境に影響しない このようなマルチアカウント管理を実現するためのベストプラクティスとして、AWS Organizations の利用が挙げられます。 AWS Organizations は複数の AWS アカウントを統合できるサービスで、アカウントを作成できるだけでなく、それらの階層化や一括したポリシー管理も可能です。 今日はこれを試してみました。 AWS Control Tower のマルチアカウント構成 terraform 参考文献 AWS Control Tower のマルチアカウント構成 AWS Organizations を有効にしたアカウントは「マスタアカ
AWS で環境を構築する際はマルチアカウントになることが多い、これは理解していたつもりでした。 stg 環境と prod 環境は AWS アカウントごと分ける。dev 環境も分ける。 しかし、世の中のベストプラクティスはもっと先を行っていました。 なぜアカウントを分けるのか isolation authz & authn auditing and reporting 世の中のマルチアカウント構成 各企業の事例 AWS が提供するベストプラクティス Gruntwork から見た AWS ベストプラクティス 各社のプラクティスから読み取れること なぜアカウントを分けるのか AWS アカウントを分ける理由は 3 つあります。 isolation authz & anthn auditing and reporting isolation そもそもとして、環境は分離しないと、というものです。 st
ほな、ここから、Cloud Mapの各リソースを解説していきます。 （ ﾟ Дﾟ） ｲﾀﾀﾞｷﾏｽ ( つ旦O と＿)_) 名前空間の作成とインスタンス検出方法の解説 AWS Cloud MapのWebコンソールにアクセスし、「名前空間の作成」ボタンをクリックします。 名前空間の作成時重要なのが、サービスインスタンスの検出方法の違い。最初にここを完全に把握しておく必要があります。 API呼び出し（API calls） サービスインスタンスの検出をAPIコールのみで実施します。具体的に利用するAPIはDiscoverInstancesで、ヘルスステータスやサービス名でのサービスインスタンス検出が可能です。 aws servicediscovery create-http-namespace --name hamako9999.com API呼び出しとVPCのDNSクエリ（API call
Route 53 リゾルバー Route 53 のマネジメントコンソールを開くと Resolver が追加されています｡ Dashboard Inbound endpoints インバウンドエンドポイントを作成します｡ VPCにはAWS側のVPCを指定してください｡SGはRoute53エンドポイント用に作成したものを選択します｡ エンドポイントを作成するAZ, サブネットはオンプレミスと通信が可能(サブネット範囲やルーティングを考慮する)な所を選びます｡ Outbound endpoins アウトバウンドエンドポイントを同様に作成します｡ ルール オンプレミス側のドメインonpremises.internalがリクエストされた時にオンプレミス側のDNS(Unbound)へ転送(Forwarding)が必要です｡この設定をRoute 53 Resolverではルールと言います｡ オンプレミス
セッションタイトル サーバレスの新しいデータストアの選択肢 S3 Select の魅力 セッション内容 サーバレスアプリを構築するときのデータストアとして皆さんは何を利用していますか？ DynamoDBが一般的ですが、NoSQL向けの設計や、検索性の低さに疲弊していたりしませんか？ より柔軟な検索性を求め、RDSを使おうとすると、VPC の概念が現れ、悩んだことはありませんか？ 2018年にGAされた S3 Select を利用すると上記の悩みが解決するかもしれません。 この発表では、サーバレスアプリのデータストアの新たな選択肢として有用な S3 Select の魅力伝えるために、下記内容を予定しています。 S3 Select の概要 使い方・サンプルコードの提供 メリット・デメリット / 向き・不向き 従来の選択肢（DynamoDBなど）との比較 実行速度などの検証結果 業務にて利用した
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く