omuronの備忘録

個人的な備忘録

AWS AppSync で GraphQL API 作成

AWS AppSync で GraphQL API 作成メモです。
ウィザードに沿って、DynamoDB をデータソースにして、API キーでのアクセスならサクッとできてしまいました。

GraphQL API 作成

AWS AppSync で API 作成

AppSync サービスを検索して、 API を作成 をクリック。

f:id:omron:20200809123626p:plain

ウィザードで作成

ウィザードで作成が選択されているので、そのまま右上の 開始 をクリック。

f:id:omron:20200809123853p:plain

モデルを作成

DynamoDB のテーブルの新規作成処理になります。
テーブル名とカラムを決めて Create をクリック。

f:id:omron:20200809124011p:plain

リソースを作成

API 名称を確定して 作成 をクリック。

f:id:omron:20200809124445p:plain

クエリを作成、検証、およびテスト

クエリメニューを利用して、データの挿入や呼び出しなどを簡単に行うことができます。

f:id:omron:20200809125016p:plain

Documentos

右側中程の Documentos をクリックすると、利用できるクエリが確認できます。
GraphQL では以下の3種類のクエリが発行できます。

  • query : レコードの select ができます
  • mutation : レコードの insert / delete / update ができます
  • subscription : レコードが更新された場合に通知を受け取ることができます

mutation

mutation を利用して、データの作成を行います。
デフォルトで createMyModelType クエリが作成されているので、 - createMyModelType をクリックして実行します。

f:id:omron:20200809125801p:plain

### request
mutation createMyModelType($createmymodeltypeinput: CreateMyModelTypeInput!) {
  createMyModelType(input: $createmymodeltypeinput) {
    id
    title
  }
}

$createmymodeltypeinput には、クエリ変数の内容が入ります。
具体的には、titleHello, world が設定されていることが確認できます。

{
  "createmymodeltypeinput": {
    "title": "Hello, world!"
  }
}

右側のペインに実行結果が表示されます。

### respons
{
  "data": {
    "createMyModelType": {
      "id": "e65f3628-947d-4e53-a0d2-125cce675132",
      "title": "Hello, world!"
    }
  }
}

DynamoDB リソースを確認するとデータが挿入されていることが確認できます。

f:id:omron:20200809130626p:plain

query

query を利用して、データの取得を行います。
デフォルトで listMyModelTypes クエリが作成されているので、 - listMyModelTypes をクリックして実行します。

f:id:omron:20200809144628p:plain

### request
query listMyModelTypes {
  listMyModelTypes {
    items {
      id
      title
    }
  }
}

右側のペインに実行結果が表示されます。

### respons
{
  "data": {
    "listMyModelTypes": {
      "items": [
        {
          "id": "e65f3628-947d-4e53-a0d2-125cce675132",
          "title": "Hello, world!"
        }
      ]
    }
  }
}

API KEY

エンドポイントとなる API URL や API KEY は、設定メニューで確認できます。

f:id:omron:20200809145306p:plain

curl を利用して、呼び出す場合の例です。
$API_KEY$API_URL は設定メニューの内容で置き換えてください。

$ curl -XPOST -H "Content-Type:application/graphql" -H "x-api-key:$API_KEY" -d '{ "query": "query { listMyModelTypes { items { id title } } }" }'  $API_URL | jq .
{
  "data": {
    "listMyModelTypes": {
      "items": [
        {
          "id": "e65f3628-947d-4e53-a0d2-125cce675132",
          "title": "Hello, world!"
        }
      ]
    }
  }
}

所感

最初に書いたとおりウィザードに沿って、DynamoDB をデータソースにして、API キーでのアクセスならサクッとできてしまいます。
API キー方式なので、クローズドな環境向けになりますが、社内向けなどのバックエンドの処理を作るのであればすぐにできそうな雰囲気をつかめました。
Cognito や OpenID Connect を利用してして認証を行うこともできたので、パブリックな API の場合はその辺りとの連携が必須になりそうです。
マネージドで簡単な分、実装が見えないので不安もありますが、裏では Lambda とかを利用しているんだろうか...?
アクセス数の制限事項やスケール特性など、大規模利用の場合は調べる必要がありそうです。

(番外編)PS4 でプレイしたゲームたち

基本的にテック系の記事しか書かないようにしているのですが、夏休みだし息抜きがてら番外編。
モンハン好きなので、モンスターハンターワールドのためだけに PS4 Pro を購入しました。
1年ほどモンハン専用機だったけど、それだけだと勿体ないと思って、違うゲームも遊んだのでそれらの備忘録として遊んだゲームの一言レビューをネタバレなしで書いてみます。

ホラー系

Resident Evil 2 (バイオハザード RE:2 北米版)

ゴア表現もすごいし、謎解きと怖さのバランスも素晴らしかった。
雑魚のゾンビが固くて本当に怖い。
最初難しかったけど、やり込むとハード・コアでも余裕になるバランス調整も素晴らしい。
神ゲーでした。

バイオハザード 7

ボスクリーチャーは怖くて謎解きも面白くてバイオハザードらしく面白かった。
今回はウイルスじゃなくてカビなので雑魚が怖くないけど、洋館に閉じ込められて雰囲気も含めてとても怖くて面白い。

バイオハザード 4

神ゲーと呼ばれてたみたいだけど、さすがに古いゲームなのでまぁそんなもんかって感じでした。
シューティングの TPS として楽しめた。

バイオハザード RE:3

あれ?もう終わり?RE:2 のバランスの良さはどこいった?
ゾンビも怖くなくなってしまってるし、ゴア表現も控えめだし、微妙なゲームだった。

サイコブレイク

昔のバイオハザード作った人が作ったゲーム。
死にゲー。とにかく死にまくる。
最初は怖くてバイオハザードっぽいけど、途中からはファンタジーな感じ。
解説記事も読んで世界観がわかると色々納得できた。
ほどほどに面白いけど、2をやりたいとは思わなかった。

オープンワールド

ファイナルファンタジー 15

これをオープンワールドに入れるかは微妙だけど...
10 以来の FF プレイ。アクションでの戦闘など思ってた FF じゃなくて「コレジャナイ」感が多かった。
主人公不幸すぎで辛い。

ウィッチャー 3

神ゲーと書かれてたけど、世界観馴染めず半日で投げた。
前作とか小説とか知ってるときっと違うんだろう。

DAYS GONE

PS4 でしたオープンワールドでは今の所一番おもしろかった。
ストーリーや世界観もいいし、大量のゾンビと戦うのが面白い。
クリア後に、ゾンビの塊を襲撃するのは歯ごたえなくて飽きたけど、ストーリー上で大量のゾンビと戦うところは本当に面白い。

ホライゾンゼロドーン

良作。
機械と弓で戦う世界観とストーリーは面白かった。
モンハンっぽいということでプレイしたけど、そこまで戦闘も面白くなく、メインストリートクリアで飽きたでダウンロードコンテンツは投げた。

スパイダーマン

町中を飛び回る爽快感素晴らしい。
でもそれだけ。ボス以外は単調なのが辛いので飽きていった。

レッド・デッド・リデンプション 2

この休み用に買ったのでまだ少ししかしてない。
今後に期待。

アクション・アドベンチャー

ラスト・オブ・アス

神ゲー
ストーリー素晴らしいし、没入感もすごい。
これはプレイしとくべきゲームだと思った。

アンチャーテッド 海賊王と最後の秘宝

ラスト・オブ・アスと同じ会社だけあって、面白かった。
プレイする映画は伊達じゃない。インディージョーンズをゲームにした感じ。
ただ、同じこと繰り返しなだけでゲームとしては飽きていく。プレイする映画として楽しめた。

デビルメイクライ 5

スタイリッシュアクションという題材からし中二病満載なゲームだった。
一応クリアしたけど面白さは理解できなかった。

絶体絶命都市 4

うーん、肌に合わない。
映像もネタも微妙だった。

龍が如く

ストーリーは良くて、ゲーム自体も面白かった。
けど、他のナンバリングをプレイしたくなるほどではなく、YouTube でプレイ動画をみるだけで満足できる感じ。
時間があればやりたいんだけど、そこまで時間をかけれないので諦め。

所感

1年半ほどで結構な数のゲームをしていた。
今どきのゲームは難易度調整もできるので、気軽に楽しめるのがいいですね。
モンハン以外にやり込んだのは RE:2 ぐらいで、ほかはそこまでやりこまずカジュアルな難易度で遊び、色々プレイする方に時間を使いました。

GraphiQL で GraphQL をお気軽に試す

GitHub が公開しているサービスの GraphiQL を利用すると簡単に GraphQL を体感できるので試してみます。

事前準備

以下の URL にアクセスすると GraphiQL サービスにアクセスできます。

URL : https://developer.github.com/v4/explorer/

Start exploring GraphQL API queries using your account’s data now

GitHub アカウントのデータを使用して GraphQL API クエリの探索を開始しましょう。
ということで「 Sign in with GitHub 」で連携して利用を許可します。

f:id:omron:20200804200129p:plain

Docs

右側の Docs から API 仕様の探索ができます。

f:id:omron:20200804200226p:plain

ユーザー情報をとるクエリを探索してみます。 Docs -> Query の順にクリックし、下にスクロールする user クエリが見つかります。

f:id:omron:20200804204021p:plain

user クエリ

user(login: String!): User

user クエリを深堀りします。
カッコの中がパラメータで、 型についている ! は必須パラメータという意味です。
login パラメータに文字列型の指定が必須であることがわかります。
戻り値は、 User オブジェクトです。

User オブジェクト

User をクリックすると、オブジェクトの詳細が見ることができます。
idbioemail など、ユーザーに紐づく情報があることがわかります。
ここでも ! がついている場合は、必ず存在します。

Explorer

user クエリを Explorer を利用して呼び出してみます。
Explorer をクリックして、 user にチェックを入れることにより、必須のパラメータ login の入力を促されます。

f:id:omron:20200804201623p:plain

ログイン情報を入力し、取得する値をなにか選択(ここでは bio )することにより、クエリが簡単に構築できます。
右三角ボタンで実行することにより、右側のペインに結果の json が表示されます。

f:id:omron:20200804202022p:plain

変数の利用

QUERY VARIABLES を利用して、JSON 形式で変数を利用できます。 loginName という変数名を、値 omuron で指定する例です。
この情報を QUERY VARIABLES に記載します。

{
  "loginName": "omuron"
}

定義した変数は query のパラメータに渡す必要があります。
変数は $ をつけることより、呼び出すことができます。

query ($loginName: String!) {
  user(login: $loginName) {
    bio
  }
}

f:id:omron:20200804202619p:plain

まとめ

GraphiQL サービスを利用することにより、 GraphQL を簡単に体感することができます。
GraphQL を呼び出す感覚を掴んでから、サーバーサイドの実装にチャレンジしていきたいと思います。

「Cybozu Tech Meetup #4 15年目プロダクトの開発スピードを上げる取り組み」 #CybozuTech 受講メモ

Cybozu Tech Meetup #4 15年目プロダクトの開発スピードを上げる取り組み - connpass

ハッシュタグ :#CybozuTech
アーカイブは後日公開。

トークメモ

生産性向上チーム
開発基盤や生産性向上取り組み、CI/CDの整備などを行う。

複数のチームが一つの Jenkins を利用。
Jenkins みんなで触ると壊れたり、誰もメンテできない状態へ。
整備専用の人がいないので、工数を避けない問題が発生。
生産性の改善は必要だと分かっていても、チーム全体で取り組むにはハードルが高い。
問題意識を持つ人がいても、それだけでは改善は難しい。

通常のプロダクト業務と、改善業務を兼務をして両方をうまくつなぐ。
結果的には生産性向上チームの深いサポートを受けられるようにする。

QA

生産性向上の改善コストや開発費全体でみてどのぐらいの割合でしょうか?コストをかけても改善すべきか参考にしたいです。

CircleCI / AWS などチーム全体からでも気軽に使えるクラウド整備なども行っている。
1スプリント=1W で、1〜2割が改善業務。
ユーザーにプロダクトの価値を届ける部分が本質なので、その程度の割合を改善業務に使っている。

専属の改善仕事人(改善チーム)がいる場合と専属はいないけどチームで改善を継続するのとどっちが長続きしやすいとお考えでしょうか?

ちょっとした改善は現場でできる。
大きな工数がかかる大変なものがある場合は、専属がいるとやりやすい。
改善をすべて専属チームに投げると続かないと思う。

生産性がどれくらい向上したかをうまく測定する方法があれば教えて欲しいです!(定量的・定性的どちらでも)

チーム立ち上げたときからの課題。
定量的に時間を測って改善を見える化するのは簡単だけど、それを続けるのは難しい。
定性的に辛いと感じているとかの方が問題なので、定性的に辛くない状態を作る。
開発者が辛くてやめられる方がダメージでかい。
定量的に出せないと納得感は出せないが、この問題の答えは出ていない。

新しいことに対する心理的障害を下げる工夫を教えていただけると嬉しいです><

個人かチームかわからないが、個人としては...
QAエンジニアをやっていて、伝統的な品質保証を学んだので、違う系列(XPとかアジャイルとか)が見えてきた。
その両方を身に着けたいと感じて、その先の CI/CD を学びたくなった。
新しいことを取り組んだ気持ちはなく、結果としてそうなった。

スクラムチームで毎週振返り、スプリントレビューなど情報共有の場があったのは大きい。
それを利用して周りを巻き込んだ。

所感

ジェンキンスおじさんがいないとメンテできなくなるだろうし、その解決のために専属や兼務、CircleCI などマネージドサービスの利用はいい改善案だと感じました。
兼務しているからこそ辛いところがわかって、改善にも時間がかけられるいいサイクルになっていそうです。
誰かが拾うべき隙間の仕事を業務としてちゃんとやる状況は大事ですし、評価されるべきと思います。

「MixLeap Live Study #60 - ヤフーECデザイナーの取り組み」 #mixleap 受講メモ

【増枠】MixLeap Live Study #60 - ヤフーECデザイナーの取り組み - connpass

後日 YouTube アーカイブを公開とのこと。

「ヤフーショッピングの品質向上に向けた意思疎通と共通の目線」

Font Type フォントのズレ
デザイナーとエンジニアのズレ

  • 共通の言語化をするにはルールが必要
    • コミュニケーション
    • 共通認識
    • 視野を広く

「ヤフーショッピングの品質向上に向けた課題解決の取り組み」

ヤフーショッピングのUI/UXデザイン

  • 運用方法のアップデート
  • デザイン仕様書尾アップデート
  • ガイドラインの導入

デザイナーでも共通認識無いのに、エンジニアと取るのは夢のまた夢

共有フォルダ分け master, workspace, release, test
( git branch みたいに分ける)

同じカラーコードでも Generic RGB, sRGB, display P3 によってずれるので注意

タイポグラフィなどをUIガイドラインにまとめる

Webアクセシビリティについて

Webアクセシビリティについて - Speaker Deck

Webアクセシビリティ:誰もがアクセスできること

ユーザビリティ:特定の人に使いやすいか
アクセスビリティ:誰にとっても使いやすいか

「ショッピングにゲームを追加!新機能「お買い物クエスト」の取り組み」

ヤフーショッピングならではのミッション。
検索結果を100件にしようとか。
経験値をためてレベルをあげて消せかえキャラカードを集めたり、スタンプや背景を手に入れたりする。

ランキングでクーポン、ガチャでもクーポン
ショッピング+ゲームでアプリに来てもらってお得情報を知ってもらう。

所感

ひっさしぶりの MixLeap です。
デザイナーさんのお話なので、タイポグラフィについてもこだわりがあるのがいい。

MixLeap のおかげで大阪でも勉強会によく行けるようになっていたのに、オフラインが開催できない状況なのは残念。
グランフロント大阪のヤフーに行けるのはいつだろう...
楽屋トークの zoom も入ってみたけど許可待ちのまま入ることができなかった。

「夏のAWSコンテナ祭り with Amazon ECS」 #ECSMatsuri 受講メモ

仕事しながら流してて気になるところだけメモりながら見てました。

オープニング セッション:Amazon ECS - ゼロから成功させるコンテナワークロード -

コンテナとは 以下をまとめたもの

  • ランタイム/エンジン
  • 依存ライブラリ/パッケージ
  • アプリケーションコード

可搬性が高く CI/CD での自動化やデリバリに活用。

とりあえず手動でデプロイ、Fargate 使うのがおすすめ。 マネジメントコンソール使って、ECS の Getting Started で作成されるタスク定義の書き換え。 copilot や docker ecs の利用。

  • 秘密情報: Secrets Manager
  • 設定値管理: SSM
  • 実行保証: Step Fuctions
  • 時間指定設定: EventBridge

CI の責務

git push -> CI でテストビルド -> ECR へ

CD の責務

ECR -> ECS

改善のイテレーションを回して自動化の文化を根付かせる。

ECSを使ったがんゲノム情報解析

がんの話は怖いけどゲノム解析の話は非常に興味深かった。

コンテナセキュリティ on Amazon ECS を改めて考える

ガードレールの必要性

ブレーキじゃなくて、道の外にはみ出ないようにして、柔軟に運転をしてもらう。

ECR のイメージスキャン

CVE データベースを利用して脆弱性の確認。

ECS on Fargateで作るスケーラブルなE2Eテスト実行基

E2E テスト

ハードルは高い。
できるだけユーザーに近い位置でのテストになる。
クリックとかマウスを動かすのは大変。
自動化後のシナリオメンテも大変。
Selenium なども利用。

その昔ECSでベストプラクティスだったものがアンチパターンになったもの、またはその逆 (仮)

トリさんの手書き Docker クジラがかわいい
いちいち説明が面白かった

  • 血も涙もない...じゃなくて血もにじむ思い
  • 出てはイケないところからログが出てる気がする...けどまぁいいか

f:id:omron:20200730105356p:plain

所感

k8s 出た頃はそちらの話ばかりだったけど、 ECS もキャズムを超えて盛り上がってきているので、情報が多くて助かります。
EKS 使う場合は、k8s + EKS という2階建ての勉強が必要で辛そうだったので、AWS に特化するならやっぱり ECS の方が安心楽ちんに使える。
当初辛かったことも改善がされていってるし、出たばかりの copilot や docker ecs まで資料化されてるスピード感が素晴らしい。
調べなくても理解して使えるレベルにはまだ達してないのでもっと慣れる必要がありそうです。
とりあえず使うなら copilot を利用するのが楽になっていきそうかな。

docker ecs コマンドを試す

docker ecs なるものが発表されて話題になってたので試してみたときの備忘録です。

aws.amazon.com

www.docker.com

GitHub にサンプルがあるので、まずは fork して試してみました。

github.com

Docker Edge

hub.docker.com

Get Edge を取得してインストールします。
これ説明をちゃんと読まずに入れた後に気がついたのですが、ローカルのコンテナイメージが全部消えてしまいます。
別の作業をしようとしたときに、「あれ、イメージがない...」となって気が付きました。

サンプル試す

GitHub サンプルローカル起動

GitHub のサンプルを試してみます。

$ git clone git@github.com:omuron/ecs-plugin.git
$ cd ecs-plugin/example/
$ docker-compose up
ERROR: no such image: <<<your docker hub user name>>>/timestamper: invalid reference format

とりあえず、サンプルをローカルで起動しようとすると、上記のエラーが発生します。
そのため docker-compose.yml の 5,6行目をコメントアウトして起動を確認しました。 無事に起動できれば、以下の URL で「Hello, Docker Folks!」という画面が確認できます。
http://localhost:5000/

f:id:omron:20200727203337p:plain

docker ecs コマンド思考錯誤

引き続き、 docker ecs コマンドを試しました。

$ docker ecs setup
Enter context name: aws
✔ docker-ecs-user
? Enter region: ap-northeast-1
? Enter credentials? [y/N] N
this tool requires the "new ARN resource ID format"

上記のエラーが発生...
ここでどう直せばいいかわからず解決できなかったところ、ハマコーさんブログで解説記事がでました!

dev.classmethod.jp

上記のブログより、以下のコマンドで解決ができることがわかりました。

aws ecs put-account-setting-default --name awsvpcTrunking --value enabled
aws ecs put-account-setting-default --name containerInsights --value enabled
aws ecs put-account-setting-default --name containerInstanceLongArnFormat --value enabled
aws ecs put-account-setting-default --name serviceLongArnFormat --value enabled
aws ecs put-account-setting-default --name taskLongArnFormat --value enabled

上記設定後、無事 docker ecs setup が完了し、 context に追加されていることが確認できます。

$ docker context ls
NAME                TYPE                DESCRIPTION                               DOCKER ENDPOINT               KUBERNETES ENDPOINT   ORCHESTRATOR
aws                 aws                                                                                                               
default *           moby                Current DOCKER_HOST based configuration   unix:///var/run/docker.sock                         swarm

ここからは、ハマコーさんの神記事があるので、真似して 参考にして進めました。

docker hub アカウント設定

以下のコマンドでログイン。

$ docker login --username omuron

README も読みながら、アクセストークンの設定を aws シークレットマネージャーに行う。

$ docker ecs secret create dockerhubAccessToken --username omuron --password XXXXX
can't use "default" with ECS command because it is not an AWS context

コンテキストを切り替えないとダメでしたので、切り替えて設定。

$ docker context use aws
aws

$ docker ecs secret create dockerhubAccessToken --username omuron --password XXXXX
arn:aws:secretsmanager:ap-northeast-1:123456789012:secret:dockerhubAccessToken-45Y3pu

上記の arndocker-compose.yml の 5行目に設定を行う。
6行目は、docker hub のアカウント omuron を設定。

ここで作成したリソースは以下の URL に当たるマネジメントコンソールで確認可能です。
https://ap-northeast-1.console.aws.amazon.com/secretsmanager/home?region=ap-northeast-1#/listSecrets

起動確認

事前準備が完了したので、以下のコマンドで起動可能。

$ docker ecs compose up

CloudFormation を確認すると example という名前のスタックが作成されて、関係リソースが構築されているのが確認できる。
EC2 内のロードバランサーメニューを確認すると、新たにロードバランサーが作成されているので、ロードバランサーDNS 名をコピーして、ポート 5000 にアクセスすると、ローカル起動と同様のサイトが確認できました。
http://exampleloadbalancer-999999999999.elb.ap-northeast-1.amazonaws.com:5000/

後始末

docker compose を落とすと削除できます。

$ docker ecs compose down

所感

最後までたどり着けたのは、ハマコーさんブログのおかげです。 本当に、ECS 含め参考になることが多いので助かります。

先日出た aws copilot に続き、 ECS を簡単に試す手段が増えてきていいですね。
CoudFormation 含め、ECS 全般を理解してないと難しい部分もありますが、ある程度把握した上で利用するととても助かるツールになりそうです。

あと、アプリを入れるときには英語でもちゃんと説明を読みましょう。 読まずに入れると、環境を壊します... 環境を壊すのがいやで、Docker 上に構築するのを基本にしてたのに、Docker 環境をふっとばしてしまいました。