Meta tags:
description=株式会社オールアバウトのエンジニアブログです。All Aboutを支えるシステムの裏側の技術などを公開していきます。;
keywords=テックブログ,エンジニアブログ,GCP,AWS,DevOps,allabout,オールアバウト;

Headings (most frequently used words):

cloud, はじめに, digital, native, leader, 最後に, 終わりに, engine, container, registory, api有効化, オールアバウトtech, blog, meetupに参加しました, meetupとは, 会場の様子, イベントトピック, アンカンファレンス, 懇親会, 新卒エンジニアとしての苦悩と成長, チームの体制と業務内容, 一年の流れ, 業務以外の活動, 成長を感じた出来事, おわりに, オールアバウト新卒エンジニアが1年で学んだこと, gcpを1ミリも知らなかった新卒が業務で学んだ知識でデプロイできるようになるまで, 使用したもの, やったこと, 参考資料, 新卒1年目を振り返って苦労したことと解決したこと, 困っていたこと, どう改善をしたのか, 株式会社オールアバウトのエンジニアブログです, google, cloudから共有, lt, グループメンバー, 議題, 具体的には, 前半, 学び編, 後半, 実践編, 自己紹介, 業務内容, 業務スケジュール, 苦労したことや学んだこと, 技術力向上のためにしたこと, コンテナとアプリ構成, php, fpmコンテナ, appサーバ, nginxコンテナ, webサーバ, cloudsql, dbサーバ, gcpで使用した主なサービス, その他, デプロイ前のgcp側の準備, appコンテナとwebコンテナのデプロイ, sqlの初期設定, sqlの接続設定, 情報量の多さ, わからない単語, 用語の多さ, 事業部とのコミュニケーションの難しさ, メディア開発1gが保持しているアプリケーションの数が多い, コードが読めない, 課題とその解決, 良かったこと, 大変だったこと, ペアプロ, コードの規模, インプットの多さ, 見積もり, 自分で手を動かし, アプリを作る, pomodoro, timer, firebase, realtime, databaseを使ったリアルタイムアプリケーション, 学んだこと, kubenetes, sql, iam, github, actions, kustomize, プロジェクト作成, kubernetes, kubernetesクラスタ作成, サービスアカウントの設定, kustomizeの設定, 正しいイメージを使用できているかの確認, コンテナ間通信, 外部アクセス, sqlのインスタンス作成, sqlのユーザー作成, サービスアカウントにロール追加, secret, オブジェクトを作成する, workload, identityを有効化する, kubernetesのサービスアカウントを作成する, サービスアカウント同士を紐づける, sqlコネクタの設定, データベースに接続する, 技術的な内容をどう噛み砕いて伝えるか, どうやって認識のずれを起こさないようにするか, 業務理解, データ構造とモデリング,

Text of the page (most frequently used words):
name (43), sample (38), #google (27), app (23), cloud (22), sql (20), project (19), image (18), kubernetes (16), nginx (16), service (16), iam (15), php (14), 2017 (13), 2023 (13), yaml (12), 2019 (11), 2020 (11), 読者になる (10), 2018 (10), kustomize (10), gcp (10), gcloud (10), web (10), 2016 (9), account (9), com (9), run (9), github (8), sock (8), クラスタ (8), fpm (8), data (8), container (8), deployment (7), secret (7), user (6), apiversion (6), kind (6), from (6), get (6), var (6), blog (5), 2022 (5), digital (5), native (5), 広告を非表示にする (5), allabout (5), techblog (5), actions (5), workload (5), apps (5), ksa (5), key (5), password (5), gserviceaccount (5), kubectl (5), serviceaccount (5), マニフェスト (5), www (5), docker (5), listen (5), edit (5), set (5), ペアプロ (5), ですが (5), オールアバウトtech (4), all (4), about (4), 2021 (4), leader (4), そのため (4), しかし (4), はじめに (4), engine (4), instance (4), spec (4), roles (4), role (4), metadata (4), create (4), mysql (4), copy (4), usr (4), conf (4), composer (4), volumemounts (4), mountpath (4), kustomization (4), firebase (4), realtime (4), javascript (4), ユースケース (4), 閉じる (3), 具体的には (3), オールアバウトグループの新卒1年目エンジニアが投稿する企画 (3), テックブログ新卒週間2023 (3), インスタンス (3), containers (3), valuefrom (3), secretkeyref (3), proxy (3), gcr (3), zone (3), accounts (3), add (3), policy (3), binding (3), member (3), literal (3), auth (3), googleapis (3), api (3), labels (3), ports (3), dev (3), storage (3), group (3), unix (3), deploy (3), deployments (3), クラウド (3), 言語化 (3), イデア (3), 読者をやめる (2), 読者です (2), rss (2), one (2), 新卒1年目を振り返って苦労したことと解決したこと (2), gcpを1ミリも知らなかった新卒が業務で学んだ知識でデプロイできるようになるまで (2), オールアバウト新卒エンジニアが1年で学んだこと (2), 新卒エンジニアとしての苦悩と成長 (2), meetupに参加しました (2), バイス (2), 終わりに (2), コードが読めない (2), メディア開発1gが保持しているアプリケーションの数が多い (2), どうやって認識のずれを起こさないようにするか (2), 技術的な内容をどう噛み砕いて伝えるか (2), わからない単語 (2), 用語の多さ (2), 情報量の多さ (2), images (2), への接続について (2), phpの公式dockerイメージでunixソケット通信しようとして罠にハマる (2), を使用してgkeにアプリケーションをデプロイする (2), autopilot (2), クラスタの作成 (2), コンテナ化されたウェブ (2), アプリケーションのデプロイ (2), マイグレーション (2), 環境変数 (2), serviceaccountname (2), env (2), username (2), database (2), port (2), resources (2), volumes (2), emptydir (2), namespace (2), オブジェクトを作成する (2), projects (2), cloudsql (2), services (2), enable (2), 有効化 (2), nodeport (2), selector (2), apt (2), install (2), system (2), ini (2), local (2), etc (2), bin (2), ソケットファイルパス (2), server (2), default (2), containerport (2), 今回は (2), ドメイン (2), imageで更新 (2), latest (2), project_id (2), json (2), admin (2), forbidden (2), チュートリアル (2), registory (2), 苦労したことや学んだこと (2), 最後に (2), pomodoro (2), ペアプログラミング (2), ペアで実装 (2), という (2), meetup (2), データ (2), モデリング (2), アーキテクチャ (2), treasure (2), 機械学習 (2), 今後のイベントのア (2), analytics (2), 限定公開記事のため引用できません, 引用をストックできませんでした, 再度お試しください, ログイン, 引用するにはまずログインしてください, ストック一覧を見る, 引用をストックしました, powered, ブログを報告する, hatena, このブログについて, 株式会社オールアバウトのエンジニアが執筆しているtech, blogです, 業務で使用している技術のアウトプットなどをしています, プロフィール, best, ベストワン, ベストが見つかるおすすめ情報メディア, qiita, organizations, 採用情報, リンク, 注目記事, 月別アーカイブ, でサービス, アカウントの権限借用, impersonate, を活用して, sre, の権限を縮小させた話, 20年以上運営してるメディアと周辺サービスの再設計, 再構築してるから話を聞いてほしい, 最新記事, 次のページ, この１年間で学んできたことを後輩に教えていければと思います, また自身も成長をするために今以上にコミュニケーションをとり, 仕事を幅を広げつつ楽しみながらやっていければと思います, 初めはそれこそ時間がかかっていたものの周りの先輩方にアド, をいただいて支えていただきながら成長をすることができた１年間だったと思います, 今回は私がチームにジョインしてから困った点に関してなぜ困ったのか, どうやって解決をしたのかについて紹介させていただきました, 今後はコードを追うことはできるようになってきたので, そこからの, 改修の際にリーダブルな実装ができるようになりたいと考えております, リファクタリング, こちらに関しては正直慣れていき読めるようになったものもありますが, 考え方としてはマクロ的視点を持って読むことだと思います, プログラミングは入力と出力の繰り返しと入社して間もない頃に先輩からアド, をいただきましたが今はそのおかげで素早くコードを読むことができています, 今まではどの行で何が行われているのかを全て把握しようとして情報量の多さに理解ができていませんでしたが, 何を引数でもらって何を出力しているのか, これを見るだけで大体の実装は理解することができるのに気づきました, またショットカットキーなどの理解も増え, 実装の内容を追うことに関してはある程度の自信がついてきました, 最も今では考え方も変わり1メソッドに1つの役割を意識して実装を心がけています, 恥ずかしながらなのですが, 入社した当初はコードから実装を理解することに関してとても苦手でした, メソッド単体程度ではある程度読解することができていたのですが, 全体を通しての処理の流れの理解ができていませんでした, チームジョイン当初はメソッドを分割しないで処理の順番で書いてくれたほうが楽なのにくらいに思っていました, この解決方法として私はよく改修の入るアプリケーションを理解するところから始めました, 大きな一つ一つのアプリケーション単位ではなくサービス同士のつながり方を意識して理解することでアプリケーションの点の理解ではなく, 線での理解に努めました, その結果一年たった今ではよく改修の入るアプリケーションに関してはシステム自体の理解, 構造の理解に関してある程度の知識をつけることができました, メディア開発gは他の開発部署に比べて扱うアプリケーションの数がとても多いです, そのためチームジョイン当初はどのアプリケーションがなんと呼ばれるシステムなのか, 理解するだけでも一苦労でした, アプリケーションがとても多いので配属されて一年経つ今ですら, システム概要に関しての理解が薄いアプリケーションもあります, このサイクルを行うことがより良いものを開発側と運用側で作るには欠かせないことだと思います, 開発側が使いやすいと思うのはあくまで推測の域を超えないため, 綿密なコミュニケーションを心がけて使用を詰めていくことがいいと思います, 再度実装する, 運用の方々に触っていただいてフィードバックをいただく, それをもとに設計し実装をする, 事業部から提案書をいただく, 少しくどいくらいに仕様に関しては質問を心がけるようにしています, 広告の表示やデザイン修正などに関しては広告が出ているか出ていないか, デザインが修正されているか, されていないかの差しかないのでそこまで認識のずれは起きづらいと思っています, 特に仕様の追加などに関しては動作検証として実際に動かしてみてもらうというのを行っています, 開発側がこれは使いやすいと思って作成したものが運用側にとってはそこまで使いやすくない, または使いずらいなんてことは往々にあると思います, 簡潔にいうならば綿密にコミュニケーションをとることです, 不安のある状態でリリースをしないということを徹底しています, などが明確になる形でのコミュニケーションを行いました, その結果デザイン修正に関してはデザインが目でみてわかる形になり, より明確に意思疎通が行えるようになりました, 仕様など機能追加に関しては事業部の方が想定した挙動ができているのか, 使いやすい機能になっているかのフィードバックももらえ, 運用の方と開発とで有用的なコミュニケーションをとることもできるようになりました, 新たにシステム内に仕様を追加するような対応では例としてボタンをクリックしたらどのような挙動をするのか, 広告表示がレイアウト調整などのfront側デザイン修正のような対応に関しては画面のモックを作成して目で見える形にする, 事実ベースというのは対応を経て何をしたいのか何ができるのかをベースに話をしていくという意味です, 技術的な内容中心に仕様に関してのコミュニケーションを取ろうとするともちろん相手に伝わりません, 事業部の方々はプログラミングに関しての知識はない方がほとんどなので技術的な内容ではなく事実ベースでのコミュニケーションを心がけました, 事業部とのコミュニケーションをとる上で難しいと感じていた点はいくつかあります, 事業部とのコミュニケーションの難しさ, 特にメディアに関する用語に関しては, 業務中に度々目にする, または利用される場面も多かったため, 自分の中で優先度を上げて覚えるように心がけていました, 初めはもちろん一番不明なことが多い時期でもありますが, その中でも少しずつ自分の糧として落とし込んでいくことでチームへのジョインもスムーズになりました, 会者固有の用語に関しては質問をする以外にはないので時間をいただいて丁寧に回答をしていただけました, デジタル単語帳という書籍を用いて学習を行う, メモをとって, わからないところは先輩に質問する, 解決方法として, 以下を実施しました, 中でもわからない用語が急激に増えたのがチームにジョインしてすぐの1, 2週間ほどでした, 開発部内ではインフラ構成周りの用語, 他チームのシステムの概要に関する用語, 一方メディアの事業部での会議体ではメディアの用語に関してがわかりませんでした, 新卒一年目で入社したタイミングから起きていた問題ではありますが, わからない用語がとても多いです, それも世間一般で使用されているもの, 会社固有の用語などもあり初めは会議体での内容もわからないほどでした, 今は業務自体に慣れてきたこともあり, 拾える情報の量も増えていますが, それでも一度に多くの情報が入ってくるタイミングはあるのでまとめて見る時間を確保して情報過多になりすぎないような努力を続けています, 解決方法として情報の重要度, 緊急性を意識するようにしました, その上で自分の中で, 今見るべきなのか今日中に見ればいいのか, と優先順位の位置付けを行うようにしました, 優先度合いががわからない場合には積極的にチーム内でコミュニケーションを取るようにして, 話し合うようにしました, 私のチームは, メディア, と名前がついていることからメディアall, aboutをはじめとしたメディアを取り扱う運用の方々とのコミュニケーションをとる機会が多々あります, 連絡ツール, 弊社ではslack, 上で目まぐるしいほどの情報が行き来をしています, 何をよく読んだらいいのか, 全部認識していないといけないのかと自問自答しながら考えていました, 外部での研修を終えた私はこれからどんな開発をしていくのだろうと心を躍らせてチームへとジョインをしました, その中で一番はじめに感じたことは, 情報量の多さです, aboutをはじめとしたメディアを取り扱う運用の方々, 事業部の方, とします, とのコミュニケーションの難しさ, 私が困っていたと感じていた点は以下になります, これから社会人一年目の私がぶつかった壁とどうやってそこに向き合って改善をしたのかについて紹介していきたいと思います, 困っていたこと, どう改善をしたのか, 本記事ではメディア開発1gのメンバーとしてジョインしたのち業務を進めていく中で苦労した点, どうやって改善をしたのかについて紹介していきます, 私は2022年4月に入社し, 6月末まで外部でのエンジニア研修を受けておりました, 研修後はメディア開発1gに所属し業務をしております, 今回はイシノがお送りします, 参考資料, に関してほぼ無知な状態から, 業務で触れる中で多少は理解できてきたと思っていました, 自分で全てをやってみるうちに, 氷山の一角でしかないという実感が強くなる一方でした, 本当はもっと業務で触れなかったサービスも使ってみようと思っていたのに既知サービスの時点で難航したこと, identityの件に気づくのが遅すぎて手が回らなかったことなど, 悔しい面はたくさんありますが, 自分の力量を知る良い機会になりましたし, 曲がりなりにもデプロイに漕ぎ着けたことはある程度自信になったと思います, 今後も, に限らず実践的な学習を続けていき, 業務に活かしていきたいです, これで直接データベースを操作できます, appコンテナに入って, を実行してから接続すれば, テーブルができています, connect, データベースに接続する, のsecretに登録した値をappコンテナの, に設定します, laravelの, envに同名の, があれば, それを上書きします, つまり, env側の記述が不要になります, proxyのargsの3番目に入る値は, のコンソールの概要, ｌこの, との接続, 接続名, から取得できます, appコンテナの環境変数を設定, db_username, db_password, db_database, connectors, args, structured, logs, 3306, securitycontext, runasnonroot, true, requests, memory, 2gi, cpu, コネクタの設定, これによりプロジェクトのサービスアカウントが様々なサービスに認証なしでアクセスできるようになります, に間違いがあった場合, overwriteオプションをつけて再実行することで更新できます, アノテーション, annotate, gke, kubernetesのサービスアカウントに, プロジェクトのサービスアカウントがどれかをアノテーションする, svc, goog, workloadidentityuser, それをプロジェクトのサービスアカウントがバインドする, kubernetesのサービスアカウントにworkload, identityのユーザーとしてのロールを付与, サービスアカウント同士を紐づける, deploymentなどと同様に, ファイルを作成し, applyすることで作成されます, のサービスアカウントを作成する, autopilotモードで, を作成すると, デフォルトで有効になっています, identityとは, 内のサービスアカウントにiamで作成したサービスアカウントを紐づけて接続する仕組みです, 認証回数が減る, サービスアカウントキーを保持する必要がなくなる, アクセス範囲を狭められるなどのメリットがあります, appコンテナとwebコンテナはまさにサービスアカウントキーを使用してしまったので, identityを用いた改善の余地があります, こちらは今後の課題とします, identityを有効化する, generic, で使えるkey, 型のオブジェクトを作成します, 後ほど, に使用します, value, proxyとはiamを用いた認証でcloud, に接続するためのコネクタです, 今回はこのコネクタの公式イメージを使用してpodにコンテナを生成して接続します, ここからのステップは以下の公式ドキュメントの, にサービス, アカウントを提供する, identity, を参考にしています, client, engine管理者ロールのあるサービスアカウントにcloud, sql接続クライアントのロールを追加, サービスアカウントにロール追加, の接続設定, users, のユーザー作成, これだけ管理コンソールで作成しました, を選択したほかはデフォルト設定です, データベースはlaravel側で, ファイルを用意しています, sqladmin, の初期設定, nodes, wide, 次のコマンドで得られる外部ipとnodeportの値をコロンで繋いで接続できます, type, 30080, 外部アクセス, confファイルをzz, confという名前に変更していることに注意してください, ここで使用している公式イメージでは, ビルド時にデフォルトのwww, confで上書きをしてしまう仕様があるようです, 辞書順で後ろになるファイルを用意すればその内容が優先になるため, 名前を変えて対応できるということのようです, asia, tokyo, update, git, unzip, libzip, libicu, libonig, ext, intl, pdo_mysql, zip, bcmath, ユーザーを作成する, addgroup, adduser, ingroup, confファイルを配置, chmod, 777, workdir, dockerfile, ユーザー設定, owner, listenに使用するユーザーを設定, mode, 0660, appコンテナ側では, ソケットファイルにアクセス可能なシステムユーザーを用意する必要があります, webコンテナ, containerportの数字, server_name, example, root, public, location, fastcgi_pass, fastcgi_param, script_filename, document_root, fastcgi_script_name, include, fastcgi_params, 上記の設定では, sockというボリュームを確保し, コンテナごとに設定したパスでマウントします, 次はnginx側の設定です, ソケットを使用しています, ソケットを用いた通信は, 通信より高速で, 同じマシン内であればデータ通信用のファイルパスを通すことで通信できます, 今回はappコンテナとwebコンテナが同一のマシンに乗っている状態なのでこの方法が可能です, とは話がずれますが, こちらもうまく接続できるまで非常に時間がかかった部分なので, どなたかの参考になることを願い簡潔に残しておきます, tcp, コンテナ間通信, describe, pods, pod, デプロイが成功したらまずこれが大事だと振り返ってみて思います, 私の場合は, podが動いていなくてpodの設定まわりを確認するのに時間を費やしてしまったのですが, 実はイメージがpushできていない, イメージを指定できていない, 古いイメージを使ってしまっているなどのミスがありました, 前セクションのocコマンドで最新のdeploymentを確認できるほか, ターミナルから次のコマンドで実際のpodで使用されているイメージを含む様々な情報を確認できます, 正しいイメージを使用できているかの確認, ちなみに, 次のコマンドもbuildができるのですが, buildした結果のdeploymentが出力されるので, に役立ちました, デバッグ, replicas, matchlabels, template, imageでkustomization, で用意した変数にイメージ名を設定し, 変数が置き換わった状態でbuildすることができます, build, apply, deployment等を作成してそれをもとにリソースを更新, imageというイメージ名変数に使用したいイメージ名を設定, yamlのあるディレクトリに移動, config, k8s, v1beta1, manifest, ファイル構成は以下の通りです, kustomizeの設定, appコンテナとwebコンテナのデプロイ, サービスアカウントは各サービスを利用するためのアカウントです, サービスアカウントにプロジェクトにおけるロールを与えると, ロールによってできることが追加されます, adminは, engineのオブジェクト全般に対する管理者, adminはcloud, storageに対する管理者ロールです, storageはプロジェクト内のオブジェクトを保持するストレージサービスなのでこちらの権限も必要になります, 出力したサービスアカウントキーは, actions側でsecretsに登録し, actionsから操作できるようにします, 今回は個人的な学習目的の環境なので大きな問題はありませんでしたが, 最近はサービスアカウントキーをci, cdツールに登録することのリスクが指摘されています, oidcや後述のworkload, identityなどを利用して直接サービスアカウントキーを登録せずに運用することができます, 弊社が, で管理しているサービスは, oidcを利用しています, keys, base64, cat, サービスアカウントキーを作成, プロジェクトに対してサービスアカウントとロールを紐づける, サービスアカウント新規作成, サービスアカウントの設定, error, cannot, resource, the, requires, permission, ツールであるkubectlを使用するには, を選択して接続する必要があります, この設定ができていないうちは下記のようなエラーが出ており, 次のセクションで出てくるような個別のロールの設定が必要なのかとしばらく誤解していました, cli, clusters, credentials, cluster, クラスタの認証情報を取得する, 作成の過程で誤って飛ばしてしまい, その結果長時間悩むことになったステップを紹介します, は以下の, を参考に作成できます, は作成の際, 標準モードとautopilotモードを選択できます, autopilotモードは設定しなくとも自動スケーリングやノード管理をある程度やってくれるようです, せっかくなので使ってみましたが, 小規模なアプリなので特に恩恵はなかったと思われます, これで該当サービスが使えるようになります, この時点でデータベースの実現方法は一旦置いていたのでcloud, 周りはまだ何もしていません, このあたりの工程から下記の記事を参考にさせていただきました, containerregistry, ブラウザの管理コンソールで作成しました, プロジェクトは, に限らず, 内の様々なサービスに跨がります, プロジェクト作成, デプロイ前の, 側の準備, 実際の手順を辿りながらハマった部分をピックアップしていきます, ローカルで動くアプリは一旦完成している状態です, やったこと, ファイルを複数まとめて管理できるツールです, 参考にした, に登場したので試しに触ってみました, 今回はデプロイ環境を一種類しか用意していないのでそこまでメリットはないのですが, ベースの, ファイルを動的に書き換えて使う方法を学べました, cdツール, コードも, で管理しています, その他, ちなみに90日間30, 分の無料トライアルを利用しました, 実は間に合わず期限後少しだけアップグレードすることになったのですが, クレジットが残っている分は引き継げるので大した負担にならなくてよかったです, サービスというより, の各サービスを使用するためのアカウント体系です, サービスなどの固有のアドレスを, という概念で並列に扱い, 様々な権限を付与します, 個人的にはここで一番よく引っかかりました, 足りない権限が何か, それをどう与えるのかがわからない, iamのサービスアカウントと, などサービス特有のアカウントとの関係がわからないなどの点で悩みました, プリンシパル, コンテナイメージを保存, 管理できるサービス, ただしイメージのストレージ自体はcloud, storageが担っています, 現在はosパッケージなども保存できるよう拡張されたartifact, registoryが推奨されています, registry, のドキュメント, ベースのリレーショナルデータベースシステムです, コンテナの自動管理ツールです, コンテナの集合体の最小単位をポッド, ポッドを実行するマシンをノード, ノード群を, ーと呼びます, ファイルでポッドの構成やスケーリングの条件などを定義しておき, トに応じて自動的にスケールさせることができます, kubenetes, で使用した主なサービス, 最終的な構成のイメージはこのようになります, システム構成, laravelのappコンテナとリバースプロキシ用のnginxのwebコンテナを自作イメージを使って立てます, これは業務で関わったものとほぼ同じ構成です, データベースには, 本番ではcloud, proxyで接続します, ローカルでは, コンテナを立てていました, 今回はデータベースに保存したテキストを取得して表示する簡単なテストページを用意しました, に接続してこれが表示できればゴールとします, ipアドレス, コンテナとアプリ構成, fpmコンテナ, appサーバ, nginxコンテナ, webサーバ, dbサーバ, 使用したもの, オールアバウトでprimead関連サービスの開発をしているhinakochiです, サービスの一つのリビルドに関わる中で, アプリをgkeでデプロイする経験をしました, 入社するまで, 自体ほぼ触ったことがなかったので, 当時はついていくので精一杯になってしまいました, 改めて何が起こっていたのかを理解するため, 一度最初から最後までを自分でやりきりたいと思いました, 約3ヶ月間, 主に平日に一日一時間程度を使って簡単なアプリのデプロイに挑戦してきたので, これを機にその過程と学んだことをまとめてみました, 遠回りが多くできたことはごくわずかですが, 少しでもどなたかの参考になれば幸いです, 2日目の投稿です, 自分自身が新卒エンジニアとして働いている1年間の中で, 業務内容や日々の業務について紹介しました, この1年間で学んだことを活かし, 今後もさらに成長していけるよう, 日々努力していきたいです, はじめてアプリづくりをするときは何を作っていいのかわからなかったり, 誰も作ったことのないサービスをつくる必要があるのでは最初は思ったりしましたが, 最初は気負わずに世の中にあるアプリを真似たものでも, 本当に簡単なものでいいなと思いました, 上に挙げたpomodoro, timerもweb上サービスとして既にあるものですが, 実装をしていく中で新しい発見や自身の実装力向上のいい機会になったと感じています, まずは, 自分が実現したいと思ったものをコードに落とし込んで, 形でできるようになることが, エンジニアとしてのファーストステップであるのかなと個人的に思います, 学んだこと, databaseとは, が提供しているfirebaseと呼ばれるプラットフォームのサービスの一つであり, リアルタイムアプリケーションを効率的に構築することができます, 業務でもこのサービスを使用したので, 勉強のためにこの技術を使ったwebアプリを作ってみました, タスク管理系, trelloみたいな, のアプリを, laravel, databaseを用いて作成したのですが, 実装していく中で, databaseの使い方や, のファイル管理の方法を考える機会もあり, いい学びになりました, オールアバウト全体の開発部勉強会が月に1回開かれるのですが, その勉強会に登壇した際に, このアプリで苦労したことを共有した際に, 色々とフィードバックをいただき, 勉強になりました, databaseを使ったリアルタイムアプリケーション, timerとはタスク集中手法の一つです, 人間の集中力の限界は25分といわれているのですが, pomodoroは25分作業5分休憩をワンセットにし, 集中力をできる限り切らさずにタスクを行うことができます, このpomodoro, timerのアプリを作った理由は, 当時業務を行う中で, を触る機会が多かったのですが, 手が止まることも多く, に慣れるためになにか自分の手で動かして作ってみようと思ったがきっかけです, timer, 私が具体的に行ったことは, 業務の中で自分自身が苦手と感じていることや, 学びたいと思っている技術分野のアプリを作ったりしました, 以下に私が作成したアプリを紹介してみます, 実装力が当初なかったことを課題に感じていたので, どうやったら力がつくだろうと色々と調べたり, 先輩に, どうやったら実装力つきますか, と聞いたりして, 自分が実践していく中で一番しっくりと来ているのは, わからないことがあったり, 作ってみたいものがあったら, 実際に手を動かして作ってみる, 自分の手を動かさず, コードを読んだり, 知識を蓄えるインプットだけだと, 理解したような気分になり, いざコードを書こうと思うと, 思ったように手が動かないことが多々あります, 実際に手を動かしてみることで, 実現したいことに対しての検索をし, コードに落とし込む実践力だったり, コードを書いていく中で, 悩む点が出てきてここはこうしたほうがよさそう, とコードをどんどんと改造していくことを学んだりできます, そういったことをしていると, 他の人が書いたコードが自分が悩んだ点を最適化するように実装されていることに気づいたり, 逆に自分だったらこう書くのにといったふうに自分なりの考えもでてくるようになり, 色々メリットを享受できていることを感じられたので, このシンプルだけど, 強力な方法は私の中でしっくりときています, で働き, 現在のosに多く採用されているダブルクリックや, を生み出した日本人エンジニアである, 中島聡氏も, 僕は何かを学ぶ際は必ず手を動かしながら, 考え学んでいる, とおっしゃっており, 優秀なエンジニアも頭の中だけで考えず, 実際に手を動かして学んでいたりします, ドラッグ, ドロップ, マイクロソフト, 自分で手を動かし, アプリを作る, 技術力向上のためにしたこと, 私の部署では, 開発を導入しており, 2週間に一回タスクをいただく機会があるのですが, その際にタスクにかかる見積もりを出す必要があります, この見積もりというものが最初はとても難しく, 見積もり段階では2時間かかると思っていたものが倍の4時間かかったりと, 想定よりも見積もり時間がオーバーしてしまうことを課題点に感じました, なので, 見積もり精度を向上させなければと思い, どのように見積もりを立てているかを先輩に伺ったところ, タスクの粒度を細かくすることが大切と教わりました, 当初は全体で〇〇時間かかりそうというぼやっとした憶測で見積もりをたてていたのですが, タスクを細かく分割して, この実装のためにはこの関数とテストが必要で, 全部足したら〇〇時間かかる, といったふうに, 詳細な実装イメージを持ちながら行うといいと知り, 見積もり精度の向上に役立ちました, 見積もり精度はまだまだ改善の余地があるので, 日々立てた見積もりのズレに対して原因を考えていき, 精度向上に努めていければと思います, アジャイル, 見積もり, とにかく新しく学ぶ情報が多かったです, 技術的なところにとどまらず, リリースやマージでの細かい作業, 日々チームとして働いていくための決まりごとなど, 当初はインプットする必要のあるものが多くあり, 学んだことはメモをとり, 次の日の朝に軽く見返すといったことをしていました, 最初はインプットすべきことが無限に感じ, 少し不安になることもありましたが, 業務を開始して半年ほどたったころから少しだけ心に余裕のない状態から抜け出し, 学んだこと一つ一つに対してじっくり考える余裕も少しずつでてきたのかなと思います, インプットの多さ, それまで個人で開発していたコードは, ファイルの量やコード行も少なく, 管理もしやすく, 修正も容易でした, チーム開発に参加すると, 他のメンバーが書いたコードを読むことになり, ファイル量やコード量もかなり感じました, その規模の大きさに驚き, どこから手をつけていいのか, 何を見ればいいのか戸惑いました, チーム開発では, 複数人で同時に同じコードを編集することもあります, その際には, コンフリクトが発生することもあり, 手順を守りながらコードをマージしていく必要がありました, 個人開発では考えられないような, コミュニケーションや手順の重要性を痛感しました, チーム開発を続けるうちに, 規模の大きなコードでも, コードの構造やコメントを活用することで読みやすくなることに気づきました, チーム開発におけるコミュニケーションの大切さを学び, チームメンバーとの協力や相談を通じて, コードの改善に取り組むことができました, コードの規模, コミュニケーション面で難しいと思った点が, 自分が実装しようとしていることをうまくペアの人に伝えられなかったという点です, 理由としては何点かあり, 実装方法を考えることに必死で, コミュニケーションをとる余裕がなく, 口数が少なくなってしまったことや, 実装方法が自分の中でも明瞭に整理できておらず, しようとしたときにできないといったことなどが考えられました, 一つ目の実装にいっぱいいっぱいになってしまうことに関しての改善方法としては, 実装に入る前にあらかじめ実装ができなさそうな点があれば予習をしてくる, ということを実践しました, 予習をしてくることで, 余裕が少しだけでてきて, 相手にも伝えることが少しずつできるようになっていけるようになってきたのかなと思います, 2つ目の, できないといった点に関しては, 上に挙げたやりたいことを口にだして書き出してみるといった方法で日々できるようになってきたと感じています, 主に配属当初は実装力強化を目標としていたこともあり, ではドライバーを担当させていただく割合が多かったのですが, ドライバーとしてやっていく中でいくつか苦労した点がありました, まず実装力の点で, 実装方法がわからず手が止まってしまってしまうことが多く, 気持ち的にも焦ってしまうことがありました, そこで教わったこととして, やりたいことを書き出してみる, そして書き出したやりたいことに対して, 必要なことを分割してさらに書き出してみるといった方法です, これは分割統治法と呼ばれる問題解決手法で, 難しい問題を細かく分割することで, 一つ一つの問題の難易度を単純なものにするというものです, 分割統治法はプログラミングにおける大切な考え方の一つであり, 自分自身, 物事を処理できるワーキングメモリの容量もそれほど大きいほうではないと感じていたので, こういった方法はとても役立ちました, 実際に自分がやりたいことを口にだしながら, 書き出していくと, されていなかった部分も自分の中で整理できて, 気持ち的にも落ち着ける効果もあり, 現在も行き詰まったときはまずは書き出してみて, 一つ一つ処理していくことを実践するように心がけています, 私のチームでは主に, の体制をとっています, 2人がペアを組んでプログラミングを行なっていく方法なのですが, 1人がドライバと呼ばれる, 実際に手を動かして実装をしていく役割の人と, もう一人がナビゲータと呼ばれ, 実装の方針などをドライバに指示する役割を担っています, 私が配属された当初ではすでにチームで, で行なっていく体制ができあがっていましたが, 在宅勤務が始まる前は部分的に, を取り入れていて, 在宅勤務に切り替わったのをきっかけに, ほぼ全ての実装を, に切り替えていったそうです, 背景としては, 在宅勤務によるコミュニケーション量の減少や, レビュー, の削減などがあったみたいです, slackで出社連絡, メールやスケジュールを確認して, 1日の動きを把握する, 開発メンバーで朝会, それぞれのメンバーが1日どんなことを行っていくかなどの動きを確認する, お昼休憩, たまに散歩にいったりして, 気分転換をする, コードレビュー, メンタータイム, メンターの方と1日の振り返りなどをしたりする, 開発メンバーで1日の振り返りや, 連絡事項を確認, slackで退勤連絡, 私のある日の業務スケジュールです, 基本的にリモートワークで, 金曜日の会議が多い日は出社します, 日によって細かい違いはありますが, 実装を重点的にやる日はこんなスケジュールです, 業務スケジュール, 開発部で, web業界における広告代理店とメディアをつなぐプラットフォームサービスの開発に携わっています, 広告代理店は, 商材を売りたいクライアントと商材を宣伝するメディア間との仲介となるものなのですが, その広告代理店とメディアとの間では, スケジュール調整や, 非一元的な情報管理, 連絡方法等の, 煩雑な業務だったりの課題点が多くあります, そのような広告代理店とメディアとの間のdx化を推進するための, サービスづくりを日々行っています, 現在は新機能開発の要件定義, 開発のタスクを任せていただいております, 業務を行う上で, やりたいと手を挙げたタスクに携われたり, 自分の意見がサービスにとって良いものだったときは, その意見が実際にサービスに取り入れられて, 反映されたときには, とてもやりがいを感じます, 業務内容, 高校までは愛知県で過ごし, 大学からは長野の大学で学生生活を過ごしていました, 大学の専攻は理系分野ではありましたが, webエンジニアとして使用していくプログラミングに関しての授業などはあまりなく, 大学2年時に, の授業を受けたぐらいでした, その時の授業でもポインタなどの説明を受けて, よくわからなかったことを覚えています, 大学院1年時にweb系のプログラミングに興味を持ちはじめたのがきっかけで, 自分でサービスを何かつくってみたいと思い, を用いて, 大学の授業を評価するためのサービスや, 自分のblogを作ったりしました, 自分は小学, 高校までサッカーをやっていた, 体育会系の人間で, あまり自分で何かを作ったりするといったような経験が少なかったのですが, そういったサービス作りの経験から, ものづくりの楽しさをジワジワと感じ始め, エンジニアを目指そうと思い, オールアバウトにエンジニアとして入社しました, フレームワーク, ruby, rails, c言語, 自己紹介, 初めまして, 株式会社オールアバウトでweb開発をしている, r_chibaです, 2022年度から新卒のエンジニアとして働きはじめて早1年経ちました, 今回は業務をしていく1年間の中で, 苦労したことや学んだことや, 日々の業務をどのように行っているかなど, 色々とつづっていければと思います, これからは, 新卒なのに, の部分が無くなります, 今後は一人のデータエンジニアとしてより深い知識と経験を身に付け, 自分なりの価値を提供していきたいと思います, おわりに, そこで, 新卒の身でありながら他社のエンジニアの方々に対して対等に議論できるようになっていることに気付きました, 一年前の自分が参加していたら, 議論どころか言葉の意味も分からず聞くことに徹していたと思うと, 確かな成長を感じた出来事です, その議論を通して他社の方からも, 新卒なのにデータのことにとても詳しいとお褒めの言葉をいただき, この一年やってきたことがきちんと身に付いていることを実感しました, イベントの参加レポートは後日, このテックブログで公開させていただきたいと思っています, 一年間業務を通して様々な経験や学びがあったと同時に, まだまだ未熟だと感じる時はあります, 業務を通して得られた知識はもちろんのこと, 自主的に学んできたことがきちんと身に付いていると確かな実感として持てた瞬間もありました, それは, 3月24日に, 主催の, leaders, データにまつわる, サービスのアップデート情報や各社の, について話し合うオフラインイベントに参加してきた時のことです, 成長を感じた出来事, 単語の数はこの1年を通して700を超え, 自分でも驚きと達成感を感じています, 密かに目標にしている, 自分の業務とは直接関係ない話の輪に入ることができる状態も目指して, 今後もこれらの活動は続けていこうと思っています, アプリケーション開発, コンピュータサイエンス, ビジネス用語, 様々なサービスやツール, データ活用やサービスの, 他社でのデータパイプライン, 単語帳に関して, 自社で現在扱っているものは学ぶことができますが, 優先順位的にまだ触れられていない技術やそもそも現在の業務だけでは得られない知識がたくさんあります, 以下のような技術的なことから一般的なことまで, 領域を定め切ってしまうのではなく, とにかく気になったものは何でも楽しく身に付けようという意識で学びました, 勉強会は主にデータにまつわる技術的な内容をカバーする目的です, 昨今では, が残る勉強会も多くなり, 活かせるものは活かして効率的に知識の獲得に繋げました, アーカイブ, 単語帳, 口頭で誰かに説明するには自信がないような理解不足な単語をとにかくシートにまとめて, ひとつひとつ調べていく, 勉強会, 月に平均して3, 4つの勉強会への参加または視聴をし, 要約や感想, 疑問をアウトプットとして, times, に投稿, 業務とは別に以下の2つを継続的に行っています, 業務以外の活動, この出来事は, 会社やチーム全体の今後のことも踏まえた上で意思決定しなくてはいけないという業務の難しさを味わった瞬間でした, データ基盤の改修を目的としてdbtというワークフローツールの調査, 共有を基本的に一人で行いました, 自社の, との相性が悪く, 色々なことを加味して今は組み込むことができないという結論に終わってしまいました, dbtはモダンデータスタックとして最近注目が集まっているツールでありデータエンジニアとして楽しみにしていた部分と, 自分が調査したゴールが, 現状では導入できない, というチーム全体にとっても悔しい結果に終わりました, 大変だったこと, もちろん適宜分からないところは追加で調べたりしましたが, 前半期にデータにまつわることと並行して学んでいた, の基礎知識が大変役に立ちました, はエンジニアにとって今や普遍的な技術となっているため, 業務を通して最低限使いこなせるようになり, それを自分で試行錯誤してみる経験ができたのは1エンジニアとして良い財産になると感じています, 開発用に作った環境は数知れず, と言えるほど多くの環境を作り上げる経験をしました, 基本的に, 何かを検証をしたり技術的な調査をするときには都度gceを使って立ち上げた新たな, に環境を構築したり, ローカルにdocker環境を作った上で作業を行っています, 良かったこと, データの収集から最終的な活用先のイメージが付いてきたため, 既存のデータ基盤の改善や社内でのbiツールのサポート等を実際に行いました, 色彩あふれる紅葉が見られるようになった10月頃のことです, 実践編, この課題に対して, まず大枠の環境ごとに格納されているデータの役割を理解し, その中の各層に分けた上でこの層とこの層との間では何を目的にどういった処理をしているかといった意味を理解するよう努めました, これにより, 対象のデータが欲しい時は大体ここを見にいけば良い, という感覚を身に付けることができました, ここで強く課題に感じたことは, あるデータを抽出したいとなった時に, どちらの環境のどのdbのどんなテーブルからどんな条件でデータを取ってくればいいか, という判断がとても難しいということでした, 最終的に用途に合わせてテーブルごとに集計されたデータを格納, ログデータの蓄積と加工, データ基盤の3層構造, データレイク, データウェアハウス, データマート, を採用しており, の2つの環境を利用しています, データ構造と, このような問題に対しては積極的に状況の切り分けを目的に質問してみたり, 一般的なことであれば自分で調べ, を自分なりに理解し, 自社状況に改めて落とし込むということを行うことで一歩一歩解決していきました, 始めは, 得た知識が一般的なことであるのか自社独自の仕組みなのかが判別しきれず, 業務知識を理解する際の妨げになっていたことが課題に感じていました, 業務理解, 課題とその解決, データパイプラインの, を学び, マルチ, であるため様々な, サービスやいくつかのbiツールなどに簡単に触れてみることから始めました, データの流れや意図を知るには自社サービスの仕組みや実際の画面上での操作も知っておく必要があるため, そういったことを教えていただきながら少しずつ知識を蓄えていきました, 実際に行った業務知識の付け方としては, とにかく地道に見て学んで疑問があったら質問をするという手当たり次第な方法です, 早速ですが, アプリケーションの開発とは異なり, データ基盤はなかなか実際に手を動かしながら学ぶということが難しいです, 体系化されている他社さんもいらっしゃるかもしれません, 少なくとも弊社では経験のあるエンジニアがデータ基盤を担当してきた経緯があり, 私のような知識がない新人が自分の力だけで理解を進めるための地盤は確立されていませんでした, 学び編, 知識を身に付けていた前半の期間と, その知識を実践に活かす後半の期間に分けてお話しします, 一年の流れ, これらの業務をメインで動けるのはマネージャーと自分の2人という状況もあり, 不安を抱えながらもやれることの多さに胸を踊らせながらチームにジョインしました, 適切な対処をするには業務知識だけでなく業界や技術的な知識など数多くのことを理解している必要があります, 実際の対応, 最終的にそれをどうやって対処するかを決める, 課題の優先順位を決める, 自分達で課題を考え挙げ出す, このような業務領域の幅広さに加えて, タスクの工程として以下のように構想から実対応までほぼ全てを自分達で行う形式を取っています, 全社的にデータ活用をより推進するための促進活動, サービス上で見たいデータについての, ングやその対応, ヒアリ, 広告運用グループと直接やり取りしながらクライアント用のレポートデータを出力, データ基盤グループが担う領域は幅広く, それ以外にも以下のようなことを行っています, biツールを活用したデータビジュアライゼーションと他部署へのサポート, データパイプライン, 収集から加工処理, biツールや外部アプリへのデータ送信といった一連のデータ処理の流れ, をメインとしたインフラの運用, チーム全体で主に以下の業務を担当しています, データ基盤グループにはメインで動けるのは2名, 兼務の方が1名の合計3名が所属しています, チームの体制と業務内容, 新卒として1年のうちにどんなことを学び, 結果的にどんな成長を実感できたかをお話ししたいと思います, 元々データに興味があり学生時代に分析や, を学んでいましたが, データの基盤どころか, webに関する知識も疎い状態でのスタートでした, 株式会社オールアバウトでデータ基盤の運用, 保守を行っている吉井と申します, 最終日4日目の投稿です, 参加レポート, 今回得たノウハウを自社のプロダクトにも活かしていきたいと思います, cloudの活用事例やソリューションを数多く知ることができる, とても良いイベントでした, アンカンファレンスでは各社のデータ活用事例について有益な生の声を聞けたため, 大変満足度が高かったです, やはり, に関わる技術領域は広く, 役職関係なく話し合いたいことが数多く積もっているようです, 参加者の中には様々な業種, 役職の方が集まっていたかと思います, アンカンファレンスや懇親会では最初の緊張感はあれど, 次第に話が盛り上がっていき全員がお互いに意見を投げかけあっていたことがとても印象的でした, トレンドのllmや, 最近特に注目されているデータメッシュやコラボレーションについての話題が熱く語られていました, さらにはイベント好評につき, の意見が出ていたりもしました, データの現在と未来の話, chatgptを主としたllmの話題, 自社データによる信頼性の担保, サービスへの活用, ガバナンス管理, データの正しい理解と使い方, 統一されたデータ, 個人情報の保護, マスク, について, cookie, データリネージ, とまではいかなくともア, 各企業が持っているデータを組み合わせて新たな価値を作り出す, ハッカソン, kaggle的なデータ分析, 各企業が持っているデータを使って, データのコラボレーション, マーケットプレイス, データメッシュ, データの, 民主化, 懇親会では以下のようなトピックが話されていました, 参加者は, cloudの社員さんも含めて30人程で, 人数がガクンと減りがちな懇親会でも参加率が高い印象を受けました, 私もですが, オフラインの貴重さをみなさん感じていたのでしょうか, イベント終了後, cloudのすぐ近くにあるお店に移り, 懇親会が開催, 懇親会, 行っている事業は違えど, 皆さんデータに対して同様の課題を抱えており, 弊社もそれで困っていて, と共感の嵐, その上で, 弊社ではこうやって対処していますよ, という風に解決策を議論していた有益な時間でした, 会社におけるデータの位置付けは, 意思決定のためなので正確なデータは必要なく, ある程度の担保がされていれば良いとしている, などを含めたデータへの理解不足をどう解決している, リネージュ, composerやpub, subにおけるサービス起因のデータ欠損に悩まされてる, bigqueryでクエリの実行時間が大幅に短縮した, 膨大なデータを取り扱う場合のデータ整備って難しいよね, データ基盤を整える上で困っていることがたくさんあって, データ活用側の, とどう向き合っている, looker, studioで, ボード用意してどうにか対処しているなぁ, ダッシュ, リテラシー, 使っている, cloudサービスや最近気になっているサービスなど, 課題に感じたこと, それに対する解決方法はどんなことをしたか, 活用事例における, cloudの, データの活用例, 私以外には, データ基盤を運用しているデータエンジニア, アナリティクスエンジニアを経て今はデータプロダクトのマネージャー, エンジニアなど多種多様な職種の方が集まっていました, グループメンバー, イベント参加者全体だと, データエンジニアやアナリティクスエンジニアが多くの割合を占めていたと思います, の社員さんがファシリテートし, 各グループごとに白熱した議論をしている様子, プライバシー保護のため, 写真にはぼかし加工を施しています, 事前のアンケートを踏まえてグループ分けされており, 約40名の参加者が1グループ5, 6人に分かれて主に以下のようなことについて話し合いました, アンカンファレンス, まだまだ, cloudを活用できる幅はたくさんあるのだということを痛感しました, ltは第2回の今回から初めて設けられましたが, 短い時間ながらも密度の濃い有益な情報盛りだくさんなお話でした, アナリストではない本日参加している, メンバーがデータ分析にどう向き合っているか, 営業職の方がデータをどう活用しているか, 製品の活用方法について, cloudのサービスをフル活用して社内外の要望に答えた, 行動情報xbigquery, 大規模, で叶えるパーソナル, bigqueryとremote, functionsの組み合わせによってレコメンドエンジンを構築, コンシェルジュ, 言語モデル, 普段から業務で, cloudを活用している企業様が, lt形式でデータの活用事例についてお話しして下さいました, データサイロとデータメッシュの話, cloudを活用して解決するデータサイロ, cloud最新アップデート情報, marketplaceから利用できるdata, analytics系のisvを紹介, lineage, logging, log, bigquery, autoscaling, object, tables, 先行して, cloudのうちどこに注力しているかが分かるのは, ユーザ目線, てもとてもありがたいです, からし, 詳しくは書けないのですが, cloudユーザにとって嬉しい今後の情報と近年話題になっているデータメッシュのお話でした, cloudから共有, イベントトピック, 食べ物については一口で食べやすいラインナップとなっていて, イベントに集中できるような流石の配慮, 飲み物はジュースからお酒まであり, 食べ物も目移りするほど充実した内容, 会場の様子, 場所は, 渋谷オフィスでのオフライン開催ということで, オンラインのイベントが多い中, オフラインのイベントは大変新鮮でした, cloud製品の最新アップデート情報や参加者同士のアンカンファレンス, さらにはデータにまつわるltを通して, 各社の事例や話を交換し合うことでプロダクト開発を加速させることが目的です, 今回のテーマは, データアナリティクス, これからのデータ戦略や, データ基盤の構築, 運用を担うデータエンジニアやデータサイエンティスト同士が集い, 語り合える場を提供します, cloudが主催したエンジニア向けの招待制meetupイベントです, meetupとは, cloudを活用してデータ基盤を構築しているエンジニアが, イベント参加者の視点で当日の様子をレポートしたいと思います, 第1弾については, が参考になるかと思います, 株式会社, magic, moment様の記事, 同名のイベントは昨年12月に開催されており, 今回はその第2弾という位置付けとなっています, に参加してきました, こんにちは, 株式会社オールアバウトでデータ基盤チームに所属している吉井です, この広告は, 90日以上更新していないブログに表示しています, 株式会社オールアバウトのエンジニアブログです,

Text of the page (random words):
てやっていく中でいくつか苦労した点がありました まず実装力の点で 実装方法がわからず手が止まってしまってしまうことが多く 気持ち的にも焦ってしまうことがありました そこで教わったこととして やりたいことを書き出してみる そして書き出したやりたいことに対して 必要なことを分割してさらに書き出してみるといった方法です これは分割統治法と呼ばれる問題解決手法で 難しい問題を細かく分割することで 一つ一つの問題の難易度を単純なものにするというものです 分割統治法はプログラミングにおける大切な考え方の一つであり 自分自身 物事を処理できるワーキングメモリの容量もそれほど大きいほうではないと感じていたので こういった方法はとても役立ちました また 実際に自分がやりたいことを口にだしながら 書き出していくと 言語化 されていなかった部分も自分の中で整理できて 気持ち的にも落ち着ける効果もあり 現在も行き詰まったときはまずは書き出してみて 一つ一つ処理していくことを実践するように心がけています 次に コミュニケーション面で難しいと思った点が 自分が実装しようとしていることをうまくペアの人に伝えられなかったという点です 理由としては何点かあり 実装方法を考えることに必死で コミュニケーションをとる余裕がなく 口数が少なくなってしまったことや 実装方法が自分の中でも明瞭に整理できておらず 言語化 しようとしたときにできないといったことなどが考えられました 一つ目の実装にいっぱいいっぱいになってしまうことに関しての改善方法としては 実装に入る前にあらかじめ実装ができなさそうな点があれば予習をしてくる ということを実践しました 予習をしてくることで 余裕が少しだけでてきて 相手にも伝えることが少しずつできるようになっていけるようになってきたのかなと思います 2つ目の 言語化 できないといった点に関しては 上に挙げたやりたいことを口にだして書き出してみるといった方法で日々できるようになってきたと感じています コードの規模 それまで個人で開発していたコードは ファイルの量やコード行も少なく 管理もしやすく 修正も容易でした しかし チーム開発に参加すると 他のメンバーが書いたコードを読むことになり ファイル量やコード量もかなり感じました その規模の大きさに驚き どこから手をつけていいのか 何を見ればいいのか戸惑いました また チーム開発では 複数人で同時に同じコードを編集することもあります その際には コンフリクトが発生することもあり 手順を守りながらコードをマージしていく必要がありました 個人開発では考えられないような コミュニケーションや手順の重要性を痛感しました しかし チーム開発を続けるうちに 規模の大きなコードでも コードの構造やコメントを活用することで読みやすくなることに気づきました また チーム開発におけるコミュニケーションの大切さを学び チームメンバーとの協力や相談を通じて コードの改善に取り組むことができました インプットの多さ とにかく新しく学ぶ情報が多かったです 技術的なところにとどまらず リリースやマージでの細かい作業 日々チームとして働いていくための決まりごとなど 当初はインプットする必要のあるものが多くあり 学んだことはメモをとり 次の日の朝に軽く見返すといったことをしていました 最初はインプットすべきことが無限に感じ 少し不安になることもありましたが 業務を開始して半年ほどたったころから少しだけ心に余裕のない状態から抜け出し 学んだこと一つ一つに対してじっくり考える余裕も少しずつでてきたのかなと思います 見積もり 私の部署では アジャイル 開発を導入しており 2週間に一回タスクをいただく機会があるのですが その際にタスクにかかる見積もりを出す必要があります この見積もりというものが最初はとても難しく 見積もり段階では2時間かかると思っていたものが倍の4時間かかったりと 想定よりも見積もり時間がオーバーしてしまうことを課題点に感じました なので 見積もり精度を向上させなければと思い どのように見積もりを立てているかを先輩に伺ったところ タスクの粒度を細かくすることが大切と教わりました 当初は全体で〇〇時間かかりそうというぼやっとした憶測で見積もりをたてていたのですが タスクを細かく分割して この実装のためにはこの関数とテストが必要で 全部足したら〇〇時間かかる といったふうに 詳細な実装イメージを持ちながら行うといいと知り 見積もり精度の向上に役立ちました 見積もり精度はまだまだ改善の余地があるので 日々立てた見積もりのズレに対して原因を考えていき 精度向上に努めていければと思います 技術力向上のためにしたこと 自分で手を動かし アプリを作る 実装力が当初なかったことを課題に感じていたので どうやったら力がつくだろうと色々と調べたり 先輩に どうやったら実装力つきますか と聞いたりして 自分が実践していく中で一番しっくりと来ているのは わからないことがあったり 作ってみたいものがあったら 実際に手を動かして作ってみる です 自分の手を動かさず コードを読んだり 知識を蓄えるインプットだけだと 理解したような気分になり いざコードを書こうと思うと 思ったように手が動かないことが多々あります 実際に手を動かしてみることで 実現したいことに対しての検索をし コードに落とし込む実践力だったり コードを書いていく中で 悩む点が出てきてここはこうしたほうがよさそう とコードをどんどんと改造していくことを学んだりできます そういったことをしていると 他の人が書いたコードが自分が悩んだ点を最適化するように実装されていることに気づいたり 逆に自分だったらこう書くのにといったふうに自分なりの考えもでてくるようになり 色々メリットを享受できていることを感じられたので このシンプルだけど 強力な方法は私の中でしっくりときています マイクロソフト で働き 現在のosに多く採用されているダブルクリックや ドラッグ ドロップ を生み出した日本人エンジニアである 中島聡氏も 僕は何かを学ぶ際は必ず手を動かしながら 考え学んでいる とおっしゃっており 優秀なエンジニアも頭の中だけで考えず 実際に手を動かして学んでいたりします 私が具体的に行ったことは 業務の中で自分自身が苦手と感じていることや 学びたいと思っている技術分野のアプリを作ったりしました 以下に私が作成したアプリを紹介してみます pomodoro timer pomodoro timerとはタスク集中手法の一つです 人間の集中力の限界は25分といわれているのですが pomodoroは25分作業5分休憩をワンセットにし 集中力をできる限り切らさずにタスクを行うことができます このpomodoro timerのアプリを作った理由は 当時業務を行う中で javascript を触る機会が多かったのですが 手が止まることも多く javascript に慣れるためになにか自分の手で動かして作ってみようと思ったがきっかけです firebase realtime databaseを使ったリアルタイムアプリケーション firebase realtime databaseとは google が提供しているfirebaseと呼ばれるプラットフォームのサービスの一つであり リアルタイムアプリケーションを効率的に構築することができます 業務でもこのサービスを使用したので 勉強のためにこの技術を使ったwebアプリを作ってみました タスク管理系 trelloみたいな のアプリを javascript laravel firebase realtime databaseを用いて作成したのですが 実装していく中で firebase realtime databaseの使い方や javascript のファイル管理の方法を考える機会もあり いい学びになりました また オールアバウト全体の開発部勉強会が月に1回開かれるのですが その勉強会に登壇した際に このアプリで苦労したことを共有した際に 色々とフィードバックをいただき 勉強になりました 学んだこと はじめてアプリづくりをするときは何を作っていいのかわからなかったり また 誰も作ったことのないサービスをつくる必要があるのでは最初は思ったりしましたが 最初は気負わずに世の中にあるアプリを真似たものでも 本当に簡単なものでいいなと思いました 上に挙げたpomodoro timerもweb上サービスとして既にあるものですが 実装をしていく中で新しい発見や自身の実装力向上のいい機会になったと感じています まずは 自分が実現したいと思ったものをコードに落とし込んで 形でできるようになることが エンジニアとしてのファーストステップであるのかなと個人的に思います 最後に 今回は 自分自身が新卒エンジニアとして働いている1年間の中で 苦労したことや学んだこと 業務内容や日々の業務について紹介しました この1年間で学んだことを活かし 今後もさらに成長していけるよう 日々努力していきたいです allabout techblog 2023 03 30 00 00 読者になる 広告を非表示にする 2023 03 29 gcpを1ミリも知らなかった新卒が業務で学んだ知識でデプロイできるようになるまで はじめに オールアバウトグループの新卒1年目エンジニアが投稿する企画 テックブログ新卒週間2023 2日目の投稿です オールアバウトでprimead関連サービスの開発をしているhinakochiです サービスの一つのリビルドに関わる中で アプリをgkeでデプロイする経験をしました 入社するまで gcp 自体ほぼ触ったことがなかったので 当時はついていくので精一杯になってしまいました 改めて何が起こっていたのかを理解するため 一度最初から最後までを自分でやりきりたいと思いました 約3ヶ月間 主に平日に一日一時間程度を使って簡単なアプリのデプロイに挑戦してきたので これを機にその過程と学んだことをまとめてみました 遠回りが多くできたことはごくわずかですが 少しでもどなたかの参考になれば幸いです 使用したもの コンテナとアプリ構成 php fpmコンテナ appサーバ nginxコンテナ webサーバ cloudsql dbサーバ laravelのappコンテナとリバースプロキシ用のnginxのwebコンテナを自作イメージを使って立てます これは業務で関わったものとほぼ同じ構成です データベースには 本番ではcloud sql auth proxyで接続します ローカルでは mysql コンテナを立てていました 今回はデータベースに保存したテキストを取得して表示する簡単なテストページを用意しました 外部 ipアドレス に接続してこれが表示できればゴールとします 最終的な構成のイメージはこのようになります システム構成 gcp で使用した主なサービス kubenetes engine コンテナの自動管理ツールです コンテナの集合体の最小単位をポッド ポッドを実行するマシンをノード ノード群を クラスタ ーと呼びます マニフェスト ファイルでポッドの構成やスケーリングの条件などを定義しておき リク エス トに応じて自動的にスケールさせることができます cloud sql クラウド ベースのリレーショナルデータベースシステムです container registory コンテナイメージを保存 管理できるサービス ただしイメージのストレージ自体はcloud storageが担っています 現在はosパッケージなども保存できるよう拡張されたartifact registoryが推奨されています 参考 container registry のドキュメント iam サービスというより gcp の各サービスを使用するためのアカウント体系です 個人 組織 サービスなどの固有のアドレスを プリンシパル という概念で並列に扱い 様々な権限を付与します 個人的にはここで一番よく引っかかりました 具体的には 足りない権限が何か それをどう与えるのかがわからない iamのサービスアカウントと kubernetes などサービス特有のアカウントとの関係がわからないなどの点で悩みました ちなみに90日間30 分の無料トライアルを利用しました 実は間に合わず期限後少しだけアップグレードすることになったのですが クレジットが残っている分は引き継げるので大した負担にならなくてよかったです その他 github actions ci cdツール コードも github で管理しています kustomize kubernetes の マニフェスト ファイルを複数まとめて管理できるツールです 参考にした チュートリアル に登場したので試しに触ってみました 今回はデプロイ環境を一種類しか用意していないのでそこまでメリットはないのですが ベースの マニフェスト ファイルを動的に書き換えて使う方法を学べました やったこと 実際の手順を辿りながらハマった部分をピックアップしていきます ローカルで動くアプリは一旦完成している状態です デプロイ前の gcp 側の準備 プロジェクト作成 ブラウザの管理コンソールで作成しました プロジェクトは kubernetes に限らず gcp 内の様々なサービスに跨がります api 有効化 container registory kubernetes engine gcloud services enable containerregistry googleapis com container googleapis com これで該当サービスが使えるようになります この時点でデータベースの実現方法は一旦置いていたのでcloud sql 周りはまだ何もしていません このあたりの工程から下記の記事を参考にさせていただきました github actions を使用してgkeにアプリケーションをデプロイする kubernetes クラスタ 作成 kubernetes クラスタ は作成の際 標準モードとautopilotモードを選択できます autopilotモードは設定しなくとも自動スケーリングやノード管理をある程度やってくれるようです せっかくなので使ってみましたが 小規模なアプリなので特に恩恵はなかったと思われます クラスタ は以下の チュートリアル を参考に作成できます コンテナ化されたウェブ アプリケーションのデプロイ autopilot クラスタの作成 クラスタ 作成の過程で誤って飛ばしてしまい その結果長時間悩むことになったステップを紹介します クラスタの認証情報を取得する gcloud container clusters get credentials sample cluster name zone zone name project sample project name kubernetes の cli ツールであるkubectlを使用するには クラスタ を選択して接続する必要があります この設定ができていないうちは下記のようなエラーが出ており 次のセクションで出てくるような個別のロールの設定が必要なのかとしばらく誤解していました error from server forbidden deployments apps deploy is forbidden user cannot get resource deployments in api group apps in the namespace default requires one of container deployments get permission s サービスアカウントの設定 サービスアカウント新規作成 gcloud iam service accounts create sample project service account プロジェクトに対してサービスアカウントとロールを紐づける gcloud projects add iam policy binding sample project name member serviceaccount sample project service account sample project name iam gserviceaccount com role roles container admin role roles storage admin サービスアカウントキーを作成 出力 gcloud iam service accounts keys create key json iam account sample project service account sample project name iam gserviceaccount com cat key json base64 サービスアカウントは各サービスを利用するためのアカウントです サービスアカウントにプロジェクトにおけるロールを与えると ロールによってできることが追加されます container adminは kubernetes engineのオブジェクト全般に対する管理者 storage adminはcloud storageに対する管理者ロールです cloud storageはプロジェクト内のオブジェクトを保持するストレージサービスなのでこちらの権限も必要になります 出力したサービスアカウントキーは github actions側でsecretsに登録し actionsから操作できるようにします 今回は個人的な学習目的の環境なので大きな問題はありませんでしたが 最近はサービスアカウントキーをci cdツールに登録することのリスクが指摘されています github actions oidcや後述のworkload identityなどを利用して直接サービスアカウントキーを登録せずに運用することができます 弊社が github で管理しているサービスは github actions oidcを利用しています appコンテナとwebコンテナのデプロイ kustomizeの設定 ファイル構成は以下の通りです deploy kustomization yaml deployment yaml service yaml kustomization yaml apiversion kustomize config k8s io v1beta1 kind kustomization resources manifest yaml service yaml images name web image name app image kustomization yamlのあるディレクトリに移動 cd deploy app imageというイメージ名変数に使用したいイメージ名を設定 kustomize edit set image app image gcr io project_id image app latest web image kustomize edit set image web image gcr io project_id image web latest deployment等を作成してそれをもとにリソースを更新 kustomize build kubectl apply f kustomize edit set imageでkustomization yaml で用意した変数にイメージ名を設定し 変数が置き換わった状態でbuildすることができます deployment yaml apiversion apps v1 kind deployment metadata name sample project labels app app name spec replicas selector matchlabels app app name template metadata labels app app name spec serviceaccountname sample ksa containers name web image web image kustomize edit set imageで更新 ports containerport 81 volumemounts mountpath var run php fpm name nginx sock name app image app image kustomize edit set imageで更新 volumemounts mountpath var run php fpm name nginx sock 後略 ちなみに 次のコマンドもbuildができるのですが buildした結果のdeploymentが出力されるので デバッグ に役立ちました oc kustomize 正しいイメージを使用できているかの確認 デプロイが成功したらまずこれが大事だと振り返ってみて思います 私の場合は podが動いていなくてpodの設定まわりを確認するのに時間を費やしてしまったのですが 実はイメージがpushできていない イメージを指定できていない 古いイメージを使ってしまっているなどのミスがありました 前セクションのocコマンドで最新のdeploymentを確認できるほか ターミナルから次のコマンドで実際のpodで使用されているイメージを含む様々な情報を確認できます kubectl describe pods pod name コンテナ間通信 今回は unix ドメイン ソケットを使用しています unix ドメイン ソケットを用いた通信は tcp 通信より高速で 同じマシン内であればデータ通信用のファイルパスを通すことで通信できます 今回はappコンテナとwebコンテナが同一のマシンに乗っている状態なのでこの方法が可能です gcp とは話がずれますが こちらもうまく接続できるまで非常に時間がかかった部分なので どなたかの参考になることを願い簡潔に残しておきます deployment yaml apiversion apps v1 kind deployment 中略 containers name web image web image ports containerport 81 volumemounts mountpath var run php fpm name nginx sock name app image app image volumemounts mountpath var run php fpm name nginx sock 中略 volumes name nginx sock emptydir 上記の設定では nginx sockというボリュームを確保し コンテナごとに設定したパスでマウントします 次はnginx側の設定です web default conf server listen 81 webコンテナ containerportの数字 server_name example com root data public 中略 location php fastcgi_pass unix var run php fpm nginx sock ソケットファイルパス fastcgi_param script_filename document_root fastcgi_script_name include fastcgi_params 中略 appコンテナ側では ソケットファイルにアクセス可能なシステムユーザーを用意する必要があります app www conf www listen var run php fpm nginx sock ソケットファイルパス user nginx ユーザー設定 group nginx listen owner nginx listenに使用するユーザーを設定 listen group nginx listen mode 0660 後略 app dockerfile from php 8 2 fpm env tz asia tokyo run apt get update apt get install y git unzip libzip dev libicu dev libonig dev docker php ext install intl pdo_mysql zip bcmath ユーザーを作成する run addgroup system nginx adduser system ingroup nginx nginx copy docker app php ini usr local etc php php ini confファイルを配置 copy docker app www conf usr local etc php fpm d zz www conf copy data run chmod 777 data storage r copy from composer 2 0 usr bin composer usr bin composer workdir data confファイルをzz www confという名前に変更していることに注意してください ここで使用している公式イメージでは ビルド時にデフォルトのwww confで上書きをしてしまう仕様があるようです 辞書順で後ろになるファイルを用意すればその内容が優先になるため 名前を変えて対応できるということのようです 参考 phpの公式dockerイメージでunixソケット通信しようとして罠にハマる 外部アクセス service yaml apiversion v1 kind service metadata name sample project service labels app app name spec type nodeport ports port 81 nodeport 30080 selector app app name 次のコマンドで得られる外部ipとnodeportの値をコロンで繋いで接続できます kubectl get nodes o wide cloud sql の初期設定 api 有効化 gcloud services enable sqladmin googleapis com cloud sql の インスタンス 作成 これだけ管理コンソールで作成しました mysql を選択したほかはデフォルト設定です データベースはlaravel側で マイグレーション ファイルを用意しています cloud sql のユーザー作成 gcloud sql users create sample db user instance sample db instance password sample db password cloud sql の接続設定 サービスアカウントにロール追加 kubernetes engine管理者ロールのあるサービスアカウントにcloud sql接続クライアントのロールを追加 gcloud projects add iam policy binding sample project name member serviceaccount sample project service account sample project name iam gserviceaccount com role roles cloudsql client ここからのステップは以下の公式ドキュメントの secret オブジェクトを作成する cloud sql auth proxy にサービス アカウントを提供する workload identity を参考にしています google kubernetes engine から cloud sql への接続について cloud sql auth proxyとはiamを用いた認証でcloud sql に接続するためのコネクタです 今回はこのコネクタの公式イメージを使用してpodにコンテナを生成して接続します secret オブジェクトを作成する kubernetes で使えるkey value 型のオブジェクトを作成します 後ほど マニフェスト に使用します kubectl create secret generic sample db secret from literal username sample db user from literal password sample db password from literal database sample db name workload identityを有効化する workload identityとは kubernetes の クラスタ 内のサービスアカウントにiamで作成したサービスアカウントを紐づけて接続する仕組みです 認証回数が減る サービスアカウントキーを保持する必要がなくなる アクセス範囲を狭められるなどのメリットがあります appコンテナとwebコンテナはまさにサービスアカウントキーを使用してしまったので workload identityを用いた改善の余地があります こちらは今後の課題とします autopilotモードで クラスタ を作成すると デフォルトで有効になっています kubernetes のサービスアカウントを作成する kubernetes service account yaml apiversion v1 kind serviceaccount metadata name sample ksa deploymentなどと同様に マニフェスト ファイルを作成し applyすることで作成されます サービスアカウント同士を紐づける kubernetesのサービスアカウントにworkload identityのユーザーとしてのロールを付与 それをプロジェクトのサービスアカウントがバインドする gcloud iam service accounts add iam policy binding role roles iam workloadidentityuser member serviceaccount sample project svc id goog sample namespace sample ksa sample project service account sample project name iam gserviceaccount com kubernetesのサービスアカウントに プロジェクトのサービスアカウントがどれかをアノテーションする kubectl annotate serviceaccount sample ksa iam gke io gcp service account sample project service account sample project name iam gserviceaccount com これによりプロジェクトのサービスアカウントが様々なサービスに認証なしでアクセスできるようになります アノテーション に間違いがあった場合 overwriteオプションをつけて再実行することで更新できます cloud sql コネクタの設定 deployment yaml apiversion apps v1 kind deployment 中略 spec serviceaccountname sample ksa containers name web 中略 name app 中略 env appコンテナの環境変数を設定 name db_username valuefrom secretkeyref name sample db secret key username name db_password valuefrom secretkeyref name sample db secret key password name db_database valuefrom secretkeyref name sample db secret key database name cloud sql proxy image gcr io cloud sql connectors cloud sql proxy 2 1 0 args structured logs port 3306 sample project name zone name sample db instance securitycontext runasnonroot true resources requests memory 2gi cpu 1 volumes name nginx sock emptydir kubernetes のsecretに登録した値をappコンテナの 環境変数 に設定します laravelの envに同名の 環境変数 があれば それを上書きします つまり env側の記述が不要になります cloud sql proxyのargsの3番目に入る値は cloud sql のコンソールの概要 ｌこの インスタンス との接続 接続名 から取得できます データベースに接続する gcloud sql connect sample db instance user sample db user これで直接データベースを操作できます appコンテナに入って マイグレーション を実行してから接続すれば テーブルができています 終わりに gcp に関してほぼ無知な状態から 業務で触れる中で多少は理解できてきたと思っていました しかし 自分で全てをやってみるうちに 氷山の一角でしかないという実感が強くなる一方でした 本当はもっと業務で触れなかったサービスも使ってみようと思っていたのに既知サービスの時点で難航したこと workload identityの件に気づくのが遅すぎて手が回らなかったことなど 悔しい面はたくさんありますが 自分の力量を知る良い機会になりましたし 曲がりなりにもデプロイに漕ぎ着けたことはある程度自信になったと思います 今後も gcp に限らず実践的な学習を続けていき 業務に活かしていきたいです 参考資料 コンテナ化されたウェブ アプリケーションのデプロイ autopilot クラスタの作成 github actions を使用してgkeにアプリケーションをデプロイする phpの公式dockerイメージでunixソケット通信しようとして罠にハマる google kubernetes engine から cloud sql への接続について images kustomize allabout techblog 2023 03 29 00 00 読者になる 広告を非表示にする 2023 03 28 新卒1年目を振り返って苦労したことと解決したこと はじめに オールアバウトグループの新卒1年目エンジニアが投稿する企画 テックブログ新卒週間2023 今回はイシノがお送りします 私は2022年4月に入社し 6月末まで外部でのエンジニア研修を受けておりました 研修後はメディア開発1gに所属し業務をしております 本記事ではメディア開発1gのメンバーとしてジョインしたのち業務を進めていく中で苦労した点 どうやって改善をしたのかについて紹介していきます 困っていたこと どう改善をしたのか...