AWS FargateでAutoScaleを試してみる - QiitaDeleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
やんないほうがいいかも、GitHub Actions の setup-xxx での依存キャッシュ保存 - 誰かの役に立てばいいブログ
GitHub Actions で CI している皆様、こんにちは。 GitHub Actions 便利ですよね。使わない日がないというくらい毎日お世話になっています。 さて、CI といえば良く問題になるのが実行時間。 長い待ち時間は開発効率を下げますし、プライベートリポジトリだと Runner の費用も嵩んでしまいます。 時間を短縮する方法は色々ありますが、一手目によく行われるのが依存パッケージのキャッシュじゃないかなと思います。 例えば Go で開発していると、依存パッケージは ~/go/pkg/mod にダウンロードして保存されます。 これを CI 実行のたびにダウンロードしてコンパイルするのは時間とお金の無駄というものです。 幸い、GitHub Actions には CI の実行間でこういった依存パッケージを保存して再利用できるキャッシュ機能があります。 詳しくは以下のドキュメントを
ECS FargateでSeleniumを実行する
はじめに こんにちは、GMOソリューションパートナーのTKです。 当社には、AWSの学習用のアカウントがあります。 今回はそれを活用して、ローカルのdocker環境上で動かしていたSeleniumを ECSのFargateで動作させてみることにしました。 構成 root ├ python │ └ Dockerfile │ └ requirements.txt │ └ script.py ├ selenium │ └ Dockerfile └ docker-compose.yml コード pythonディレクトリ配下 FROM python:3.12 ENV TZ Asia/Tokyo RUN apt-get update && \ apt-get install -y sudo vim && \ apt-get clean COPY ./ /app RUN pip install -r /
生成AI入門 - AWS社員が解説するAmazon Bedrock詳細ハンズオン - Findy Tools
公開日 2024/09/05更新日 2024/09/06生成AI入門 - AWS社員が解説するAmazon Bedrock詳細ハンズオン はじめにAmazon Bedrockは、業界をリードする種々の基盤モデル（Foundation Model・FM）を提供する、生成AIアプリケーションの構築に必要な幅広い機能を備えたフルマネージドサービスです。 生成AIを業務で導入するには、モデル選びやセキュリティなど、さまざまなことを考える必要があります。 Amazon Bedrockは、APIを通じて生成AIの基盤モデルを利用できるだけでなく、付随するサービスによってお客様が生成AIを簡単に導入できます。 Amazon BedrockはAWSマネジメントコンソール上でモデルを有効化し、API経由で入力を送信するだけで使用できます。コンソールでモデルを試したり、複数モデルを比較したりすることもできます
reboot/shutdown後も設定を維持したい場合はulimit -nではなく/etc/security/limits.confを編集する(「Too many open files」「ファイルを開きすぎています」エラー対策) - Qiita
reboot/shutdown後も設定を維持したい場合はulimit -nではなく/etc/security/limits.confを編集する(「Too many open files」「ファイルを開きすぎています」エラー対策)CentOSRHELRHEL7centos7 RHEL7/CentOS7上で開発や運用をしていると「Too many open files」「ファイルを開きすぎています」といったエラーが出ることがあります。これはファイルディスクリプタの枯渇が原因であり、その上限値を調整することが対策法となります。 さて調査の結果、ファイルディスクリプタの上限値はulimit -nにより設定できることが分かったのですが――ulimitによる設定は一時的な効力しかなく、rebootやshutdownをすると、もともとの値に戻ってしまいます。 [root@localhost ~]# ul
Linux サーバでの「Too many open files」対策について - akishin999の日記
Linux サーバでの「Too many open files」エラー対策について調べたのでまとめてみました。 確認した OS は CentOS 5.9 と CentOS 6.3 です。 「Too many open files」は Linux でプロセスが開けるファイルディスクリプタの上限に達してしまうと発生するエラーです。 「ファイルディスクリプタ」という名前ですが、 Linux ではソケットもファイルディスクリプタなので、ファイルを開いた場合だけでなく、ソケットを使って通信を行う場合にもファイルディスクリプタが使用されます。 そのため、Apache や Tomcat などで高負荷なサイトを運用している場合などには、比較的遭遇する確率の高いエラーではないでしょうか。 このエラーを回避するため、プロセスがオープンできるファイルディスクリプタの上限を変更します。 まずは以下のコマンドを実行
Amazon Verified Permissionsな世界とAmazon API Gateway - Qiita
はじめに AWS Verified AccessやAmazon Verified Permissionsって紛らわしいですよね。どっちがどっちだかわからなくなるところなのですが、今回は、Amazon Verified Permissionsを使った認可制御についてのアーキテクチャを考えます。 ゴールとしては、Amazon Verified Permissionsはどんなやつなのか理解する、です。 Amazon Verified Permissionsとは Amazon Verified Permissionsは、アプリケーションのアクセス許可の管理およびきめ細かな承認サービスです。制御については、ポリシー言語である Cedar を使用して、ロールと属性を使用してポリシーベースのアクセス制御を定義し、よりきめ細かくコンテキストに応じたアクセス制御を行うことができます。 単純に認可だけするサー
Amazon S3が「条件付き書き込み」に対応。既にオブジェクトがある場合は上書きせず、分散アプリケーションでの利用が容易に
Amazon Web Servicesは、オブジェクトストレージを提供する「Amazon S3」の新機能として「条件付き書きこみ」（Conditional Writes）をサポートしたことを発表しました。 条件付き書き込みを利用すると、オブジェクトの書き込み時にオブジェクトの存在をチェックし、オブジェクトが存在しない時だけ書き込む、という指定が可能になります。 これにより、アプリケーションがデータをAmazon S3に書き込む際に、既存のオブジェクトを上書きすることを簡単に防ぐことができるようになります。 例えば、複数のクライアントが同一オブジェクトにデータを書き込んでいくような分散処理において、不用意に既存のデータを上書きしないように書き込む直前にオブジェクトを確認するといった処理をアプリケーションで作りこむ必要がなくなり、Amazon S3に任せることができるため、Amazon S3を
DMARCポリシー「none」または DMARC 対応していないドメイン名のなりすましフィッシングメール増加傾向、7 月のフィッシング報告状況 | ScanNetSecurity
フィッシング対策協議会は8月21日、2024年7月のフィッシング報告状況を発表した。
お名前.comからRoute53にドメイン移管する - Qiita
概要 お名前.comのドメインをRoute53に移管する際、設定で迷ったのでメモしておく。 ドメインの移管 移管可能なドメイン 移管する際は、下記条件を満たしている必要があるようです。 ドメインレジストラに登録後、60日経過している 期限切れのドメインの場合、期限切れから60日経過している ドメインレジストラに移管してから、60日経過している ドメインのステータスコードが次の状態でないこと ※ pendingDelete, pendingTransfer, redemptionPeriod, clientTransferProhibited ドメインのステータスコードは、whoisコマンドで確認 ドメイン設定の確認 (お名前.com） ドメインの設定内容をチェックする。 > お名前.com Navi -> ドメイン ※ ドメインを移行できるようにアンロックになっているか？ ※ ドメインの登
Terraform担当大臣 - laiso
“Platform Engineering”という私的よく見かけるが意味を調べたことのない用語No.1のトピックについて書かれた本がO'Reillyからearly releaseされているので読んでる。まだ第一部しか公開されてない。 learning.oreilly.com その中に出てくるアプリケーションチームがTerraformコードを管理することで起きがちな問題について共感したので紹介する アプリケーションエンジニアリングチームがIaaSクラウドのあらゆるものを求めるようになったとき、多くの企業は、各チームに独自のクラウドインフラストラクチャを独自の構成でプロビジョニングする権限と責任を与えることが、摩擦の少ない方法だと判断しました。 実際には、これは、構成管理とインフラストラクチャプロビジョニングに精通した、兼業のクラウドエンジニアリングチームになることを意味していました。 繰り返
systemdにバグ．/home以下のファイルが全削除される可能性あり - pyopyopyo - Linuxとかプログラミングの覚え書き -
systemdのバージョン256に /homeディレクトリ以下のファイルを削除してしまうバグがあったそうで，修正版の 256.1 がリリースされています． systemdのissuesによると，一時ファイルを一括削除する systemd-tmpfiles --purge コマンドが /home以下を不要ファイルと誤判定して削除するそうです tmpファイルを消すだけのコマンドと見せかけて，home以下も消すという邪悪なバグなので注意が必要です． 心配な人は systemd のバージョンを確認しておきましょう systemdのバージョンの確認方法 以下のコマンドを実行してsystemdのバージョンを確認します $ systemctl --version バグ有り，/homeが消える可能性がある場合 １行目にsystemd 256 (256-1)と表示されます．バグあり版です．何かの拍子に/ho
オンプレエンジニアがAWSを触って思ったのと違うと感じたこと - Qiita
はじめに この仕事を始めた当初(約20年前)はオンプレミスという言葉がありませんでした。いや厳密には私の周りではパブリッククラウドとオンプレミスを分けて話す人はおらず、インフラ構築といえば今でいうオンプレミスが中心でした(世の中的にはパブリッククラウドがサービスとして存在していました)。オンプレミスみたいに新しい概念が出てきた時にそれまでの概念を説明するためにできる言葉をレトロニムというそうです。 私が本格的にパブリッククラウドの仕事をし始めたのは約3年前でAWSでした。研修ではAzureを先に触れていたのと、この本を読んでいたという知識があった程度です。 ここではずっとオンプレミスのインフラ構築をしていた私がAWSに触れて最初に戸惑ったことを記事したいと思います。また、戸惑いましたということだけ書いても学びがないため対応したことも併せて記載します。AWSに慣れている人からすれば常識ですが
金融庁のサイバーセキュリティに関するガイドラインを読んだ話 - LayerX エンジニアブログ
LayerX Fintech事業部*1で、セキュリティ、インフラ、情シス、ヘルプデスク、ガバナンス・コンプラエンジニアリングなど色々やってる @ken5scal です。 今日はFintech事業部らしく、金融庁が意見募集をしていた「金融分野におけるサイバーセキュリティに関するガイドライン」（案）*2について感想を記載します。 具体的には、よかったな〜とおもうところ、きになったところ、最後にルールメイキングやっていこうぜ！という内容です。 もちろん良い子のFintechのみんなは提出したよね？ www.fsa.go.jp 本邦におけるサイバーセキュリティの確保について「サイバーセキュリティ基本法」を軸として各種施策が定められています。 その中で当社Fintech事業部が取り組むような証券サービスは「重要社会基盤事業者（重要インフラ事業者）」に位置づけられています。これは証券サービスが「他に代
2024 年 5 月と 6 月の AWS Black Belt オンラインセミナー資料及び動画公開のご案内 | Amazon Web Services
Amazon Web Services ブログ 2024 年 5 月と 6 月の AWS Black Belt オンラインセミナー資料及び動画公開のご案内 2024 年 5 月および 6 月に公開された AWS Black Belt オンラインセミナーの資料及び動画についてご案内させて頂きます。 動画はオンデマンドでご視聴いただけます。 また、過去の AWS Black Belt オンラインセミナーの資料及び動画は「AWS サービス別資料集」に一覧がございます。 YouTube の再生リストは「AWS Black Belt Online Seminar の Playlist」をご覧ください。 AWS Cost Explorer AWS Cost Explorer は、コストと使用状況を表示および分析するために使用できるサービスです。本セッションでは、AWS Cost Explorer の概
セキュリティ・バイ・デザイン「システム開発のセキュリティ向上0.0」 | デジタル人材の育成 | IPA 独立行政法人 情報処理推進機構
背景 近年、サイバー攻撃の件数は増えており、また手法も多様化・巧妙化しています。自社をサイバー攻撃から守るセキュリティはもちろん重要ですが、自社がシステムベンダなら、顧客に提供するシステムのセキュリティも重要です。顧客に提供するシステムが保有する脆弱性は、攻撃者に利用され、顧客の事業被害（ビジネス中断や情報漏洩など）に繋がるリスクをもたらします。ゆえに、システムベンダは顧客に提供するシステムに責任を負う事になります。 このような背景から、開発チームでのセキュリティ対応が喫緊の課題となっていますが、その一方で、開発チームは、新規システム開発や既存システムの新機能追加、バグ修正等で多忙な日々を送っているかと思います。例えば、目下の納期を守るため、すぐには問題にならないセキュリティ対策を後回しにして、結局対応できないという場合もあるかもしれません。 しかし、開発チームが「多忙なので、開発時にセキ
Bulk insertでも20時間以上かかっていたMySQLへのインサート処理を1時間以内にする - エムスリーテックブログ
この記事はエムスリー Advent Calendar 2022の30日目の記事です。 前日は id:kijuky による チームメンバーのGoogleカレンダーの休暇予定一覧をスプレッドシート+GASで作った でした。 AI・機械学習チームの北川(@kitagry)です。 今回はMySQLへのインサートを20倍以上高速化した話について書きます。 仕事をちゃんとしてるか見張る猫 TL; DR はじめに 今回のテーブル バイナリログを無効化する 追試 LOAD DATA INFILE 追試 テーブルの正規化 インデックスを一時的に剥がす まとめ We are hiring!! TL; DR バイナリログをオフにする LOAD DATA INFILEを使う インデックスを一時的に消す はじめに AI・機械学習チームではサイトトップからアプリに至るまで多くの推薦システムがあります。 そこでは推薦ロ
望ましい自動テストとは｜どのようなテストが開発生産性と開発者体験を共に高めるのか｜Tech Team Journal
自動テストの重要性が広く認知されるようになった一方、自動テストの活用に課題を抱える組織も依然として多く見受けられます。 本記事では『Developer eXperience Day 2024』（主催：日本CTO協会）における和田卓人氏によるセッション「望ましい自動テストとは：どのようなテストが開発生産性と開発者体験を共に高めるのか」の内容をお届けします。 和田卓人氏 執筆活動や講演、ハンズオンイベントなどを通じて自動テストやテスト駆動開発を広めようと努力している。 『プログラマが知るべき97のこと』（オライリージャパン、2010）監修。『SQLアンチパターン』（オライリージャパン、2013）監訳。『テスト駆動開発』（オーム社、2017）翻訳。『事業をエンジニアリングする技術者たち』（ラムダノート、2022）編者。 なぜ自動化テストを書くのか 和田 卓人です。インターネット上ではt-wada
Terraform AWS プロバイダーを使用するためのベストプラクティス - AWS 規範ガイダンス
翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 Terraform AWS プロバイダーを使用するためのベストプラクティス マイケル・ビギン、アマゾン・ウェブ・サービス、シニア DevOps ・コンサルタント (AWS） 2024 年 5 月 (ドキュメント履歴 ) で Terraform を使用して infrastructure as code (IaC ) を管理すると、一貫性、セキュリティ、俊敏性の向上などの重要な利点 AWS が得られます。ただし、Terraform の設定のサイズと複雑さが大きくなるにつれて、落とし穴を避けるためにベストプラクティスに従うことが重要になります。 このガイドでは、 から Terraform AWS プロバイダーを使用するための推奨ベストプラクティスについて説明します Has
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「分かりやすいネットワーク図」の描き方
