並び順

ブックマーク数

期間指定

  • から
  • まで

1 - 40 件 / 40件

新着順 人気順

GoogleAppEngineの検索結果1 - 40 件 / 40件

GoogleAppEngineに関するエントリは40件あります。 データベースdatabaseDB などが関連タグです。 人気エントリには 『Linuxコンテナの「次」としてのWebAssembly、の解説』などがあります。
  • Linuxコンテナの「次」としてのWebAssembly、の解説

    はじめに WASMをブラウザの外で動かすトレンドに関して「Linuxコンテナの「次」としてのWebAssemblyの解説」というタイトルで動画を投稿したのですが、動画では話しきれなかった内容をこちらの記事で補完したいと思います。 2022年もWebAssembly(WASM)の話題が多く発表されましたが、そのひとつにDocker for DesktopのWASM対応があります。FastlyやCloudflareもエッジ環境でWASMを動かすソリューションを持っていますし、MSのAKS(Azure Kubernetes Service)でもWASMにpreview対応しています。WASM Buildersでも2023年のWASMの予想としてWASMのアプリケーションランタイム利用に関して言及されました。 WASMといえば元々ブラウザ上で高速にC++のコードなどを実行するところから始まっている

      Linuxコンテナの「次」としてのWebAssembly、の解説
    • リレーショナルデータベースシステムを趣味で開発している者です。 現在、開発中のシステムを並行トランザクションへ対応させることを検討しており、どのような手法があるのか調べたところ、SS2PLもしくはS2PLという手法が私と同じように自作をされている方々の中では多く採用されているようだと分かりました。 一方で、PostgreSQLやMySQLなどのプロダクションレベルで利用されているシステムではMVCCと呼ばれる手法が採用されているということも分かりました。 きっと後者の方が多くの場合で高いスループットが得ら

      リレーショナルデータベースシステムを趣味で開発している者です。 現在、開発中のシステムを並行トランザクションへ対応させることを検討しており、どのような手法があるのか調べたところ、SS2PLもしくはS2PLという手法が私と同じように自作をされている方々の中では多く採用されているようだと分かりました。 一方で、PostgreSQLやMySQLなどのプロダクションレベルで利用されているシステムではMVCCと呼ばれる手法が採用されているということも分かりました。 きっと後者の方が多くの場合で高いスループットが得られるということなのだと思うので、可能であればMVCCを採用したいのですが、あまり初学者向けの実装例も見当たらず、どうしたものかと悩んでおります。 SS2PL/S2PLとMVCCの実装の難易度・工数はどの程度違うものなのでしょうか? また、初めてリレーショナルデータベースシステムを開発する者

        リレーショナルデータベースシステムを趣味で開発している者です。 現在、開発中のシステムを並行トランザクションへ対応させることを検討しており、どのような手法があるのか調べたところ、SS2PLもしくはS2PLという手法が私と同じように自作をされている方々の中では多く採用されているようだと分かりました。 一方で、PostgreSQLやMySQLなどのプロダクションレベルで利用されているシステムではMVCCと呼ばれる手法が採用されているということも分かりました。 きっと後者の方が多くの場合で高いスループットが得ら
      • 30分でわかるデータ指向アプリケーションデザイン - Data Engineering Study #18

        600ページを超える書籍である「データ指向アプリケーションデザイン」の要点を最近の話題を交えながら解説します。 Data Engineering Study #18 の発表資料です プレゼンテーション https://www.youtube.com/watch?v=ZiKWXc0fSCw …

          30分でわかるデータ指向アプリケーションデザイン - Data Engineering Study #18
        • MySQLのインデックスですが、B-treeではなくB+treeを使用するのはどうしてなのでしょうか? | mond

          MySQLのインデックスですが、B-treeではなくB+treeを使用するのはどうしてなのでしょうか? 端的に言うと性能が良いからです。 これを理解するにはバッファプールへの理解が必要です。ディスク指向のデータベースの上では有限のメモリを最大限活用することでメモリに入り切らない巨大なデータ群に対して良好な参照性能を出す必要があります。バッファプールとはディスク上のデータの羅列を固定サイズのページ(InnoDBの場合16KB)の羅列であるとして読み書きに必要な分だけをメモリに移し取り複数の書き込みをできる限りメモリ内で受け止めて後でまとめてディスクに書き戻すという、ライトバック型のキャッシュのような機構です。 この中においてバッファプールは有限のサイズしか無いので適宜プール内のデータを書き戻して入れ替えながら上手くやっていく必要があります。 さてB+treeとB-treeの最大の違いは木のリ

            MySQLのインデックスですが、B-treeではなくB+treeを使用するのはどうしてなのでしょうか? | mond
          • 開発者が知るべきキャッシュ設計でよく遭遇する問題

            はじめに 分散システムの設計および開発において、キャッシュはパフォーマンス向上のための非常に重要な要素です。頻繁にアクセスされるデータをキャッシュすることで、アクセス速度が遅いデータベースへのアクセスを削減し、データへの迅速なアクセスを可能にします。これにより、システムの全体的な効率とパフォーマンスが向上します。 しかし、キャッシュは慎重に設計しないとむしろパフォーマンス上のデメリットになるケースが存在します。 この記事ではよく遭遇するキャッシュ設計の問題とその回避策について解説します。 Cache penetration DBに存在しない値を検索したときに、DBから返された空の結果をキャッシュしない場合に発生するシナリオです。 このシナリオではDBに存在しない値を繰り返し検索することにより、その値がキャッシュされていないため検索ごとにDBへのアクセスが必要になってしまいます。 存在しない

              開発者が知るべきキャッシュ設計でよく遭遇する問題
            • 2021年サーバーサイドのエンジニアが使ってよかったもの10選 - KAYAC Engineers' Blog

              こんにちは! Tech KAYAC Advent Calendar 2021 7日目を担当する荒賀(@ken39arg) です。 カヤックのエンジニアブログには2008年にPHPを使ったガラケー関連の記事を書いたのが最初になります。 それから10年以上たち、ガラケーも弊社でのPHPのプロジェクトもほぼなくなり、メンバーもかなり入れ替わり、私自身も20代だったのがついに40歳になりました。そんな私にとってこのアドベントカレンダーは私は今でもここにいるよというPingのような役割になっているため、年に一度若者に混じってアドベントカレンダーに参加しております。 例年ですと、趣味のマラソンなどに関する実績も書いているのですが、昨年同様、今年も続くコロナ禍により多くの大会が中止となったためこちらに関しては特に特記すべき実績はありません。ただ2020年に走るはずだった東京マラソンは権利は移行を続けてお

                2021年サーバーサイドのエンジニアが使ってよかったもの10選 - KAYAC Engineers' Blog
              • yamlについて思うこと

                yaml、どうしてこんなに使われているのだろうか。kubernetesにも責任があるというのはありそうな話だけど、色々考えてみるとそこまで簡単な話でもなさそうな気がする。例えばtravis-CIの設定ファイルがyamlであったりというように、この分野ではyamlは割と広く使われていたんじゃないかという気がする。思い起こせばGoogle AppEngineもapp.yamlに設定を書いていたし、設定にyamlというのは割とよくあることであった、のではないかなあ。 しかしなぜyamlなんだろうか。yamlのフォーマットには問題がたくさんあることが知られているし、自分も全く好きではない。 例えばyamlの問題の一つとして、キーに任意のデータ構造を持ってこれるという話があり、これが一部のプログラミング言語で問題を厄介にしている。またエイリアスがあってデータ構造がツリーにならない(複数の経路から同じ

                  yamlについて思うこと
                • Next.jsアプリをVercelからGoogle Cloudに移行した話

                  ZennではフロントエンドにNext.jsを使っています。もともとはVercelで動かしていたのですが、2021年3月にGoogle Cloudに移行しました。今回は移行を決めた理由や、具体的な構成、移行作業などについて書きたいと思います。 なぜ移行したのか Next.jsのデプロイ先としてVercelは圧倒的に優れています。ISRやImage OptimizationといったNext.jsの強力な機能をサーバー側の追加設定なしで使用できますし、CDNでの静的ファイルのキャッシュなども特に意識しなくてもいい感じにやってくれます。 Vercel以外にデプロイするとなると、Next.jsの一部の機能がうまく動かなかったり、パフォーマンス・チューニングを自分で頑張る必要があったりと自分で面倒を見なければならない部分が多くなります。 しかし、Zennのケースでは以下のような理由からVercelから

                    Next.jsアプリをVercelからGoogle Cloudに移行した話
                  • AWSで“データのサイロ化”を防げ すべてのデータを1ヶ所に集めるデータレイクの作り方 | ログミーBusiness

                    リーガルテック領域のリーディングカンパニーである株式会社LegalForceが、「検索インフラTechTalk!」を開催しました。インフラ領域の中でも「検索インフラ」にフォーカスした今回は、検索インフラに関する具体的な事例や取り組みについて各スピーカーから発表がありました。野口真吾氏は、AWSを用いたデータレイクの基礎について紹介しました。 企業規模に関係なく起こるデータのサイロ化野口真吾氏(以下、野口):みなさんこんばんは。本日は「検索インフラ Tech Talk!」ということで、検索インフラから少し広げた話題にはなるんですが、「AWSを用いたデータレイクの基礎」というお話をします。よろしくお願いします。 最初に簡単に自己紹介します。アマゾンウェブサービスジャパンでスタートアップ担当のソリューションアーキテクトをしている野口真吾と申します。Twitterでは@nogというIDを使って活動

                      AWSで“データのサイロ化”を防げ すべてのデータを1ヶ所に集めるデータレイクの作り方 | ログミーBusiness
                    • 日本語の問いをChatGPTでSQLに変換、実行する「Chat2Query」を搭載。MySQL互換のTiDB Cloud

                      日本語の問いをChatGPTでSQLに変換、実行する「Chat2Query」を搭載。MySQL互換のTiDB Cloud MySQL互換のオープンソースデータベース「TiDB」(タイデービー)を提供しているPingCAP社は、日本語を含む自然言語の問いをChatGPTを用いてSQL文に変換し、実行する「Chat2Query」機能を、クラウド上でTiDBのマネージドサービスを提供する「TiDB Cloud」にβ版として搭載したことを発表しました(日本語のプレスリリース) Introducing #Chat2Query, our AI-powered natural language querying tool that will release you from tedious manual SQL writing and change the way of #DataExploration

                        日本語の問いをChatGPTでSQLに変換、実行する「Chat2Query」を搭載。MySQL互換のTiDB Cloud
                      • なぜ今も Google App Engine を選ぶのか - ぽ靴な缶

                        Google Cloud で何かアプリケーションを動かしたい時、いつも App Engine (GAE) を第一の選択肢として挙げています。 なのにみ〜んな Cloud Run に行ってしまう。なぜなのか?? 確かに Cloud Run のほうが新しくて公式に露出が多いし、GAE はこういうランディングページからの言及も消えているので無理もない。Google Cloud 的にもあんまり使って欲しくない雰囲気が漂っている。 cloud.google.com App Engine は GCP 最初期からあるサービスで今年で 14 年目になるらしい。 当時学生だった僕はすげーのが出たぞと聞いて GAE を触っていた記憶がある。その頃は Google App Engine 単体で出ていて、他のサービスが続いて Google Cloud Platform になったような気がする1。 そんな歴史あるサ

                          なぜ今も Google App Engine を選ぶのか - ぽ靴な缶
                        • ワークフローオーケストレーション入門

                          「Data Engineering Study #23 Data orchestration 特集」の発表資料です イベントページ: https://forkwell.connpass.com/event/310011/

                            ワークフローオーケストレーション入門
                          • Cloud Native時代のデータベース

                            2021/6/11 #InfraStudy 2nd Season

                              Cloud Native時代のデータベース
                            • マイクロサービス環境におけるDB戦略 in DMMプラットフォーム

                              Database Engineering Meetup #2 の登壇資料です。 https://scalar.connpass.com/event/310641/

                                マイクロサービス環境におけるDB戦略 in DMMプラットフォーム
                              • オープンソースによるFirebase代替を名乗るBaaS「Supabase」が正式サービスとして提供開始

                                オープンソースによるFirebase代替を名乗るBaaS(Backend as a Service)「Supabase」が正式サービス化を発表しました。 Supabaseはこれまで約4年間ベータ版としてサービスを提供してきました。現在は100万以上のデータベースをホストし、新規データベースも1日あたり2500以上増加しており、モバイルアプリケーションからエンタープライズ用途まで十分な機能と安定性、スケーラビリティが実証されたとしています。 Supabaseの主な機能はデータベースや認証、ファイルストレージなど SupabaseはBaaSとして主に以下のマネージドサービス群から構成されています。 PostgreSQLによるデータベースサービス 認証サービス ファイルストレージ エッジロケーションにおけるNode.jsDenoベースのサーバレス基盤 マルチプレイヤーゲームなどに対応するリアルタ

                                  オープンソースによるFirebase代替を名乗るBaaS「Supabase」が正式サービスとして提供開始
                                • [速報]分散PostgreSQLをAzure Cosmos DBが提供開始、オープンソースの分散DBエンジン「Citus」を採用。Ignite 2022

                                  [速報]分散PostgreSQLをAzure Cosmos DBが提供開始、オープンソースの分散DBエンジン「Citus」を採用。Ignite 2022 マイクロソフトは現在開催中のイベント「Microsoft Ignite 2022」で、グローバル規模の分散NoSQLデータベース「Azure Cosmos DB」でPostgreSQLをサポートする「Azure Cosmos DB for PostgreSQL」を発表しました。 Cosmos DBはデータを自動的にユーザーの近くのリージョンにレプリケーションすることで、どのユーザーに対しても高速なデータベースアクセスを実現し、かつグローバルな規模で稼働する大規模分散NoSQLデータベースです。 最大で数ペタバイトのデータ容量と秒間数百万トランザクションまでスケールする性能をカバーできる点を特徴としています。 Azure Cosmos DB

                                    [速報]分散PostgreSQLをAzure Cosmos DBが提供開始、オープンソースの分散DBエンジン「Citus」を採用。Ignite 2022
                                  • RedisをフォークしたインメモリDBの「Valkey」、次期バージョンでは性能が2倍以上に

                                    オープンソースの代表的なインメモリデータストア「Redis」のフォークとしてLinux Foundation傘下で開発が進められている「Valkey」は、AWSやGoogle Cloud、Oracle Cloudなどへの採用が始まっています。 参考:Google Cloud、Redisをフォークした「Valkey 7.2」のマネージドサービス「Memorystore for Valkey」プレビュー版を開始 8月2日に、フォーク後の最初のメジャーバージョンとなる「Valkey 8.0」のリリース候補版が公開されたのに合わせて、Valkey 8.0で予定されている性能や機能の向上についての記事「Valkey 8.0: Delivering Enhanced Performance and Reliability」がValkeyのブログに投稿されました。 その内容から、Valkey 8.0の主

                                      RedisをフォークしたインメモリDBの「Valkey」、次期バージョンでは性能が2倍以上に
                                    • ノーチラス・テクノロジーズとNEC、メニーコアと大容量メモリに最適化した国産の次世代インメモリデータベース「劔(Tsurugi)」発表。アーリーアクセス版公開

                                      ノーチラス・テクノロジーズとNEC、メニーコアと大容量メモリに最適化した国産の次世代インメモリデータベース「劔(Tsurugi)」発表。アーリーアクセス版公開 日本電気株式会社と株式会社ノーチラス・テクノロジーズは、NEDO(国立研究開発法人新エネルギー・産業技術総合開発機構)のプロジェクトとして開発をしてきた国産のリレーショナルデータベース管理システム「劔(Tsurugi)」のアーリーアクセス版の公開を発表しました(開発者の神林氏による解説「劔"Tsurugi"とは何か」)。 劔の最大の特徴は、メニーコア、大容量メモリといった最新のハードウェアに対して最適化されたインメモリデータベースとして最初から設計、開発されていることです。 これは、現在主流となっているリレーショナルデータベース製品の多くが10年以上前のコンピュータハードウェアの主流であったシングルコアやデュアルコアなど少数のプロセ

                                        ノーチラス・テクノロジーズとNEC、メニーコアと大容量メモリに最適化した国産の次世代インメモリデータベース「劔(Tsurugi)」発表。アーリーアクセス版公開
                                      • リリース後に落ちないように、新規サービスで備えておいたこと

                                        こんにちは、エンジニアの@tarrです。 前回の連載記事ではマルチクラウドなどを使い、Blocksでは最大限落ちないようにリスクヘッジをしながらシステムを構築しているという記事を書きました。 AWSが落ちてもGCPに逃がすことで落ちないシステムを作る技術 今回の記事は、リリース前の状態で、どのように負荷に対応するシステムを構築したかという話です。 リリース前のシステムで、スパイクやユーザー数の急激な増加を予測して、スケールするシステムを作るのは非常に難しいです。 どのように使われるのか、どのような量のリクエストが来るのかを正確に予測することがしづらいからです。 一方で、リリースのタイミングでいきなり落ちてしまって、機能しないものを提供するわけにもいきません。 また、無限にコストをかけることもできないため、コストにも配慮した落とし所を探る必要もあります。 今回は、Blocksがリリース前にス

                                          リリース後に落ちないように、新規サービスで備えておいたこと
                                        • FractalDB: LINEヤフーのオンプレミス・マルチテナンシー型データベースシステムの紹介

                                          こんにちは、LINEヤフー株式会社でデータベース部門に所属している、今野です。現在は、先日LINEヤフー社内にて提供を開始したFractalDBの開発と運用を担当するチームに所属しています。 FractalDBは、LINEヤフーのオンプレミス環境に向け開発された、データベースプラットフォームです。この記事では、FractalDBの概要として、開発に至った背景や設計目標から、その特徴およびアーキテクチャの概要について紹介します。 また、LINEヤフーでは今夏のインターンシップを募集しています。FractalDBチームも募集してますので、ページの最後の紹介をぜひ確認してみてください。 FractalDBとは FractalDBは、LINEヤフーのオンプレミス環境に最適化されたデータベースプラットフォームとして開発されています。リレーショナルデータベースとNoSQLデータベースの利点を融合させた

                                            FractalDB: LINEヤフーのオンプレミス・マルチテナンシー型データベースシステムの紹介
                                          • 「教員は学生を育てるクリエイター」~すがやみつる氏に聞く研究者・教育者としての足跡

                                            マンガ『ゲームセンターあらし』をはじめ、数々の人気作で知られるマンガ家・小説家のすがやみつる氏。2020年には新刊『ゲームセンターあらしと学ぶプログラミング入門 まんが版こんにちはPython』を上梓し、注目を集めた。またすがや氏は、京都精華大学マンガ学部の教授として、多くの学生を世に送り出してきた人物でもある。2021年3月の退職を機に、研究者・教育者としての足跡について聞いた(写真はすべてすがや氏提供)。 INTERVIEW_小野憲史 / Kenji Ono EDIT_三村ゆにこ / Uniko Mimura(@UNIKO_LITTLE)、海老原朱里 / Akari Ebihara 大学の教員を退職し、再びクリエイター活動へ CGWORLD(以下、CGW):遅ればせながら、京都精華大学を退職おめでとうございます。 すがやみつる氏(以下、すがや):2020年3月に専任教員を定年退職して、

                                              「教員は学生を育てるクリエイター」~すがやみつる氏に聞く研究者・教育者としての足跡
                                            • Cloud Monitoring を支える 分散グローバルデータストア「Monarch」

                                              「GCPUG Shonan vol.74」で使用予定のスライドです。 https://gcpug-shonan.connpass.com/event/243711/

                                                Cloud Monitoring を支える 分散グローバルデータストア「Monarch」
                                              • How I Hacked Google App Engine: Anatomy of a Java Bytecode Exploit

                                                  How I Hacked Google App Engine: Anatomy of a Java Bytecode Exploit
                                                • わかる!Firestore

                                                  tl;dr Firestore は NoSQL のサーバーレスデータベース。 新規開発ならネイティブモードを選択する。 ドキュメント指向のデータモデルを採用していて、コレクション、ドキュメントの階層構造で構成される。 サブコレクションを使うと効率よくクエリができる。 直近のアップデートで、より使いやすくなった。 はじめに みなさん、こんにちは。Google Cloud パートナーエンジニアの Sho です。 この記事は Google Cloud Japan Advent Calendar 2022(今から始める Google Cloud ) の 12/11 の記事です。本記事では、Firestore を取り上げてご紹介させていただきます。 Cloud Spanner や AlloyDB など特徴的なデータベースラインナップを持つ Google Cloud ですが、その中でも NoSQL デ

                                                    わかる!Firestore
                                                  • GAEのサービス間通信にはデフォルトのドメインを使うと速いという話

                                                    追記) サービス間通信に関わらず、東京リージョンではカスタムドメインを使うとレイテンシが増加 sinmetalさんにコメントで教えていただきました。 お察しの通り、Tokyo Regionを含むいくつかのRegionのApp EngineはCustom DomainでアクセスするとLatencyが増加します。 ドキュメントとしては https://cloud.google.com/appengine/docs/standard/ruby/mapping-custom-domains?hl=en に書いてあります。 確証はないですが、GoogleのネットワークのエッジポイントにあるGoogle Frontend Serverは、App EngineのCustom Domainの紐付けを持っておらず、us-central1に一度行ってしまうために、発生するLatencyなのではないかと思います

                                                      GAEのサービス間通信にはデフォルトのドメインを使うと速いという話
                                                    • Google App EngineへのNext.jsアプリケーションデプロイで気付いた課題と対策

                                                      はじめに 今回は、Google App Engine に Next.js アプリケーションをデプロイした際に遭遇した課題と、それぞれの対応について紹介します。 npx create-next-app コマンドの実行後にデプロイした際に、以下の課題に遭遇しました。 next/image を利用している画像へのリクエスト時に App Engine 上で書き込みエラーが発生する App Engine のイメージサイズが400MB弱程度と大きい App Engine のパフォーマンス改善のためのウォームアップリクエストの構成方法が分からない 1. next/image を利用している画像へのリクエスト時に App Engine 上で書き込みエラーが発生する next/image を利用することで、WebP 対応や画質の調整、画像のサイズに応じた配信など簡単に実現することができます。詳しくは、Nex

                                                        Google App EngineへのNext.jsアプリケーションデプロイで気付いた課題と対策
                                                      • How Litestream Eliminated My Database Server for $0.03/month

                                                        Here’s a riddle. My web app keeps all of its data in a SQL database. I can spontaneously tear it down, deploy the code to a different hosting platform, and the app will still serve all the same data. Running my app in production costs $0.03 per month. How is this possible? That’s easy. You have a separate database server running somewhere that stores all of your app’s state. No, my app never talks

                                                          How Litestream Eliminated My Database Server for $0.03/month
                                                        • 音声系サービスにおけるサーバーレスアーキテクチャの活用について

                                                          NTT Tech Conference 2022(2022年3月23日開催) 「音声系サービスにおける サーバーレスアーキテクチャの 活用について」 (講演者:西谷 智広[NTTコミュニケーションズ株式会社])の講演スライドです。 GCPのサーバーレスアーキテクチャを使ってNTTコミュニケーシ…

                                                            音声系サービスにおけるサーバーレスアーキテクチャの活用について
                                                          • App EngineとCloud CDNの設定方法まとめ

                                                            GCPのApp Engine(GAE)とCloud CDNを合わせて使う方法について、ググってもあまり解説が見つからなかったのでまとめておきます。 GAEとCloud CDNを合わせて使うメリット GAEにはエッジキャッシュがデフォルトで備わっています。レスポンスのヘッダーでCache-Control: public, max-age=86400などと指定するだけでレスポンスがGoogleのエッジサーバにキャッシュされます。 残念ながら、このエッジキャッシュについて公式ドキュメントがほとんど見つかりません。 GAEのエッジキャッシュが使えるならCloud CDNは不要では? GAEのエッジキャッシュは気軽に使えて楽なのですが、キャッシュを明示的に削除することができないという難点があります。アプリの新しいバージョンをデプロイしてもしばらくは古いキャッシュが表示され続けてしまったりするので、本

                                                              App EngineとCloud CDNの設定方法まとめ
                                                            • Bigtableで分散カウンタ機能が正式に利用可能に。SQLのクエリにも対応

                                                              Google Cloudは、NoSQLデータベースとして提供しているBigtableの新機能として分散カウンタを正式版にしたことを発表しました。また、SQLクエリのサポートもプレビュー機能として提供を開始したことを合わせて発表しました。 Bigtableで分散カウンタ機能が正式版に Bigtableはキーバリューストア型のNoSQLデータベースであり、高度なスケーラビリティを備えつつ高速で低レイテンシな性能を提供することを大きな特徴としています。 こうしたBigtableのスケーラビリティと高い性能を実現する仕組みとして、デフォルトで採用されているのが「結果整合性」です。 結果整合性では、最終的にデータベースのデータが集約されて整合性を備えるのに一定の時間を必要とする場合があります。 そのため、例えばカウンタのように、データベース上のある値に1を足した値をデータベースに書き込む処理では、1

                                                                Bigtableで分散カウンタ機能が正式に利用可能に。SQLのクエリにも対応
                                                              • 【個人開発】約25時間でバレンタインなTwitter webサービスの作成してリリースしました! - Qiita

                                                                はじめに 2日くらい前に突然webサービスのアイデアが浮かびました。 バレンタインにも合いそうなwebサービスなので、とにかく速く製造してリリースするという目標でやってみました。 どんなwebサービス chocopoi 「ちょこぽい」というwebサービスです。 twitterで見かけた気になる人にchoco(≒いいね)をひそかに送るサービスです。 (twitter認証が必要です) ※ホントのチョコを渡すわけではありません。「いいね」を送るとお考え下さい。 バレンタインに、下駄箱を開けるとチョコが入っててドキドキみたいなのが体験できないかな? という思いつきから作ったwebサービスです。 chocoを渡す方法は簡単! まず送りたい相手のユーザー名や@の名前を入れて、検索してください。 送りたいユーザーがでたら選択し「chocoをあげる」ボタンを押すだけ! これでchocopoiちょこぽいアカ

                                                                  【個人開発】約25時間でバレンタインなTwitter webサービスの作成してリリースしました! - Qiita
                                                                • Google App Engineではじめる, らくらくTV砲対策 - AIワクチン接種予測の舞台裏 - JX通信社エンジニアブログ

                                                                  JX通信社シニア・エンジニアの@shinyorke(しんよーく)です. ちょっと前のお話になりますが, JX通信社のニュース速報アプリ「NewsDigest」で, 「AIワクチン接種予測」という新機能の提供を開始しました. prtimes.jp 「自分がいつコロナワクチンを接種できるか?」を簡単に予測できるサービスです. 使っていただけると嬉しいです🙏 大変ありがたい事に,「AIワクチン接種予測」はリリース後多くの反響を頂いていまして, リリースから約半月で利用回数が100万回を突破(プレスリリース). 同じく, リリースから半月で20本以上ものTV番組で紹介 と, 多くのユーザーさんにお使いいただきました. ありがとうございます🙏 これだけ多くの方に使っていただくとなると, リクエスト数・ユーザー数の増減に合わせたコンピューティングリソースの配分 特に, 「TV経由で認知したユーザー

                                                                    Google App Engineではじめる, らくらくTV砲対策 - AIワクチン接種予測の舞台裏 - JX通信社エンジニアブログ
                                                                  • FireStoreのイベントをトリガーとして、Eventarc経由でCloudRunを呼び出す

                                                                    (これはこの記事からの転載です) FireStoreのイベントは、Eventarcを用いることで他のサービス、例えばCloud Runなどをトリガーできます。 今回、Eventarcを用いてFireStoreのイベントをトリガーとしてCloud Runを呼び出してみることにします。 EventarcはAuditとPub/Subの両方から流し込むことができます。PubSubはCloud PubSubとして他のいろいろなところから流し込むことができ、AuditはFireStoreのイベント以外にもGoogle Cloudで起きるほぼすべてのAPI呼び出しをイベントとして流し込めます。 1. 取得したいイベントの監査ログを有効化する 最初にEventarcを有効化する監査ログの種類を指定し、有効化します。 IAM権限管理 -> 監査ログ で、 "Firestore/Datastore API"

                                                                      FireStoreのイベントをトリガーとして、Eventarc経由でCloudRunを呼び出す
                                                                    • key-value storeを設計するにあたって,リカバリのためにwalを設計するとします。walを可変長にしたい場合,各wal recordにrecord長を表すheaderをつけるような実装が素直な実装の一つとしてあると思うのですが,wal recordを格納しているファイルが破損し,あるwal recordのheader部分が信頼できなくなった場合,各recordの長さがわからなくなってしまうため当該wal record以降のすべてのwal recordが信頼できなくなるような弱点があるように思え

                                                                      key-value storeを設計するにあたって,リカバリのためにwalを設計するとします。walを可変長にしたい場合,各wal recordにrecord長を表すheaderをつけるような実装が素直な実装の一つとしてあると思うのですが,wal recordを格納しているファイルが破損し,あるwal recordのheader部分が信頼できなくなった場合,各recordの長さがわからなくなってしまうため当該wal record以降のすべてのwal recordが信頼できなくなるような弱点があるように思えるのですが,この問題はうまく回避できるのでしょうか 前提として世の中にあるデータベースは基本的にログファイルが破損する事を想定していません。ログは信頼できるストレージに複製込で保存されており、化けたり消えたりする事はないという前提を置いています。想定する一番大きな障害でもMedia Fai

                                                                        key-value storeを設計するにあたって,リカバリのためにwalを設計するとします。walを可変長にしたい場合,各wal recordにrecord長を表すheaderをつけるような実装が素直な実装の一つとしてあると思うのですが,wal recordを格納しているファイルが破損し,あるwal recordのheader部分が信頼できなくなった場合,各recordの長さがわからなくなってしまうため当該wal record以降のすべてのwal recordが信頼できなくなるような弱点があるように思え
                                                                      • Cloud Armorを使って、サーバーレスなサービスに対して特定の国からのアクセスをブロックする | inthisfucking.world

                                                                        GAE (standard) に対して、ロードバランサー及びVPCからのトラフィックのみを受け付けるようにする設定が追加されました。詳しくはこの記事のGAEの項目を参照ください。 External HTTP(S) Load BalancerとCloud Armorの関係 External HTTP(S) Load Balancerは、Googleのpoints of presence (PoPs) において実装されています。Googleのpopとは、Googleのネットワークへの入り口のようなもので、世界中に沢山存在しています。Googleのサービスへのアクセスは、これらのpopを通り、Googleのデータセンターに到達します (厳密には、使用しているGCPのVPCがPremium Tierかどうかが関係しています)。 “Google Cloud Armor security policy

                                                                        • 勝手に増えていくCloud Storageのコンテナイメージを自動で削除する | SERVERSUS

                                                                          公開日: 2021.2.8 Google App Engineを使っていると、いつの間にかCloud Storageの使用量が勝手に増えて課金されるようになります。今回はこの現象の原因と解決策についてまとめました。 編集ノート:SERVERSUSでは、パートナーリンクからコミッションを得ています。コミッションが記事の意見や、サービスの評価に影響を与えることはありません。 無料なはずなのに・・App Engineでいつ間にか課金が Google App EngineはGoogle Cloud PlatformのAlways Free対象プロダクトなので、無料で利用することが出来ます。 しかし、ある程度使っているとある日から突然Google Cloud Platformから請求のメールが届いてびっくりします。他のプロダクトを使っていないのであれば、Cloud Storageの課金になっているこ

                                                                            勝手に増えていくCloud Storageのコンテナイメージを自動で削除する | SERVERSUS
                                                                          • Cloud Bigtable の規模 | Google Cloud 公式ブログ

                                                                            ※この投稿は米国時間 2021 年 6 月 9 日に、Google Cloud blog に投稿されたものの抄訳です。 「低レイテンシと高スループットを必要とするアプリケーションを構築している場合」- 大量の読み取りと書き込みに対応できるデータベースが必要です。Cloud Bigtable は、まさにこの処理を前提として設計されています。 Cloud Bigtable はフルマネージド、ワイドカラム型 NoSQL データベースで、ペタバイト規模まで対応可能です。低レイテンシ、大量の読み取りと書き込み、大規模でのパフォーマンスの維持に向けて最適化されています。数ミリ秒単位の超低レイテンシを実現します。時系列のオペレーションや MapReduce スタイルのオペレーションに最適なデータソースです。Bigtable はオープンソースの HBase API 規格をサポートしているため、HBase、

                                                                              Cloud Bigtable の規模 | Google Cloud 公式ブログ
                                                                            • GAE/Pythonでサービスアカウントキーファイルを使わないようにした - Pirika Developers Blog

                                                                              こんにちは。ピリカ開発チームの伊藤です。 GCPの各種サーバーレスサービスにアクセスするには、認証情報が必要となります。App EngineやCloud Functions上で動作している場合は、GCPの各種ライブラリを使っていれば特に何もしなくても認証が通った状態となり、FirestoreやCloud Storageなどを扱うことができるようになっています。 しかし、ローカルでの動作確認を行う場合など、GCP外で動く場合には認証情報を渡す必要があります。 これまで、ローカルでの認証のためには「サービスアカウントキー」というJSONファイルを取得することが多かったのですが、サービスアカウントキーファイルが漏洩した場合に検知が難しいなどの問題があり、最近は非推奨となっています。 では具体的にどのようにすれば良いのかというと、あまりまとまった情報がありませんでした。 今回は、GAE/Pytho

                                                                                GAE/Pythonでサービスアカウントキーファイルを使わないようにした - Pirika Developers Blog
                                                                              • Herokuが有料化するのでdiscord botをGAEに移した - Qiita

                                                                                クラウドの料金やサービスに関する記述は全て記述時のものです。最新の情報は適宜確認してください。 TL;DR Heroku有料化後のDiscord botを無料で置ける場所を考えた botに簡単な非同期httpサーバを実装して、Google App Engineにデプロイした 今のところ無料で安定稼働してる discord botの置き場問題 私は趣味で小規模なdiscord botを2年ほど運用しています。 インフラにはデプロイの手軽さと、無料で使えるということからherokuを使ってきたので、有料化するというニュースには驚きました。 なるべくお金はかけたくないので、移行先を考えました。 移行に当たっての考慮ポイントは以下の通りです。 なるべく低料金(できれば無料)であること 運用負荷が小さいこと pythonが動作すること なるべく使ったことがないインフラであること 勉強のためです AW

                                                                                  Herokuが有料化するのでdiscord botをGAEに移した - Qiita
                                                                                • Serverless NEGを使ってApp Engineにカスタムドメインをワイルドカードマッピング - 株式会社カブク

                                                                                  ご存知の通り、Google App Engineにデフォルトで割り当てられるドメインは{project_id}.appspot.comですが、{version}-dot-{service}-dot-{project_id}.appspot.comでアクセスすればバージョンやサービスを指定できます。App Engineにカスタムドメインを割り当てていても同じことができて、{version}.your_custom_domain.comのようにすれば、(dispatch.yamlをいじっていなければ)デフォルトサービスの指定したバージョンにアクセスできます。自分のチームでは開発ブランチの動作確認などに使っています。めっちゃ便利です。 しかし、App Engineの公式ドキュメントにはとても恐ろしいことが書いてあります。 カスタム ドメインを使用すると、一部のリージョンで App Engine

                                                                                    Serverless NEGを使ってApp Engineにカスタムドメインをワイルドカードマッピング - 株式会社カブク
                                                                                  1

                                                                                  新着記事