融合知能デザイン研究室エンジニアブログ

CeleryのBrokerとResultBackendをElastiCache(Redis)からSQS+DynamoDBに移行した話

2024-07-20T03:58:50Z

はじめに

Crowd4u開発チームではAWSのコストを$200減らすために行ったことやしがないエンジニアがレガシーコードに向き合った感想のとおり、AWSのコスト削減やレガシー改善への取り組みを続けています。

今回は、AWSでElastiCache(Redis)が月30ドル以上かかっており、コスト削減の際に問題となったため、RedisをSQSに移行するまでは書いていきます。

Celeryとは

CeleryはPythonベースの分散タスクキューツールです。

Pythonでの柔軟かつ信頼性の高いタスクキューとして、Pythonベースのウェブサービスを作成する際によく用いられています。

Celeryにはタスクキューとして使うCELERY_BROKERと必要に応じてタスクの結果を格納するCELERY_RESULT_BACKENDを設定します。今回は、CELERY_BROKERだけでなく、RESULT_BACKENDも使用する必要がありました。

AWSでのCELERY_BROKERの選択肢

AWS上でのCELERY_BROKERの主な選択肢として以下の3つがあります。

ElastiCache
Amazon MQ
Amazon SQS

現在、私たちが開発しているシステムではElastiCacheを使用しています。

しかし、ElastiCacheやAmazon MQはインスタンスを建てるため時間単位で課金されます。そのため、常にリクエストが何万件も来るシステムならともかく、そうでない場合は必要以上のコストがかかります。

一方で、Amazon SQSはリクエスト単位での課金かつ、毎月100万リクエストまでは無料のため大幅な節約となります。そのため、SQSへ移行することとしました。

SQSではRESULT_BACKENDを受け取ることができない…

さて、以上のような理由でSQSへの移行を決めましたが、現在のシステムではRESULT_BACKENDを使用していますが、SQSではRESULT_BACKENDを受け取れないため別で用意する必要があります。

こちらの主な選択肢としては

S3
RDS(RDBMS)
DynamoDB(noSQL)
メモリ

のような選択肢があります。今回はDynamoDBを選択しました。理由としては、コスト面(RDSにも無料利用枠が存在しますが)、スケーリングの対応がしやすい点などが挙げられます。

どう実現するか

今回の構成の実現にあたり、以下のようなceleryconfig.pyを作成し、Celeryに読み込ませるような形で実現をしています。環境変数は.envやAmazon Secret Managerなどを使用して読み込んでください。

import os
from kombu.utils.url import safequote

broker_url = "sqs://{aws_access_key}:{aws_secret_key}@".format(
	aws_access_key=safequote(os.environ.get["AWS_ACCESS_KEY"]),
  aws_secret_key=safequote(os.environ.get["AWS_SECRET_KEY"]),
)
		        
broker_transport_options = {
	"region": os.environ.get("AWS_REGION", "your_region"),
  "visibility_timeout": os.environ.get("AWS_SQS_VISIBILITY_TIMEOUT", 3600),
  "polling_interval": os.environ.get("AWS_SQS_POLLING_INTERVAL", 1),
  "wait_time_seconds": os.environ.get("AWS_SQS_WAIT_TIME_SECONDS", 15),
  "queue_name_prefix": os.environ.get("AWS_SQS_QUEUE_NAME_PREFIX", "hoge-"),
}

# change dynamodb 'table name'
result_backend = f"dynamodb://@{os.environ.get('AWS_REGION', 'your_region')}/table_name"

以上のような設定により、BROKERにSQS、 RESULT_BACKENDにDynamoDBを設定することができます。ちなみに、SQSのキューに関しては特に何も設定しなかった場合は「celery」という名前のキューが自動で生成されるみたいですね。今回の場合はqueue_name_prefixでPrefixを指定し、hoge-celeryというような名前のキューが作成されるようにしています。

最後に、これらのコードを実行するIAMロールやIAMユーザーにSQSとDynamoDBのRead権限やWrite権限を与えるようなインラインポリシーを作成してアタッチして下さい(ここのポリシーは省略します)。

おわりに

今回はSQSへの移行を行いましたが、当然環境によってはElastiCacheやAmazon MQが最適な選択肢となる場合は多く存在すると思います。たとえば、SQSを使用する場合はCeleryイベントやリモートコントロールコマンドに対応していないといった問題があり、SQSを使用する際には自分たちで監視・ヘルスチェックのための環境が必要と言えるでしょう(現在はこちらの対応はできていませんが、順次作成していかないとなとは思っています...)。

以上のような理由により、CeleryのBrokerやBackendの適応先はサービスの運営状況と合わせて選定する必要なあるなと感じています。

ここまで読んでいただきありがとうございました！

出典

令和5年に爆誕したオレオレFWの話

2023-12-23T15:00:00Z

この記事はklis Advent Calendar 2023の記事となります。

こんにちは、klis19（3編）のnotch_manです。今日はクリスマスイブですね。皆さんはいかがお過ごしでしょうか。私は仕事が多すぎてクリスマスどころか年末年始も消滅する見込みです。今日はクリスマスイブにピッタリな一家に1つあると嬉しいオレオレFWの紹介をします。街中のカップルを眺めて心が寒くなった皆さん、愛を持ってオレオレFWを育てて豊かな人生を歩みましょう！

※対象はWebアプリケーションフレームワークと思ってください

免責事項

この記事は主観がとても強いです。また、融合知能デザイン研究室で1年以上もPythonでWebを書くという苦行を経て辿り着いた1つの作法です。一般的な問題を解決するわけではないので、あまり真に受けないでください。オレオレを現場に持ち込んだ場合、同僚に嫌われます（経験談）

オレオレFWとは

オレオレFWとは自作のフレームワークのことを指します。巷で有名なものだとDjangoやFlask、LaravelやRailsなどがいわゆるWebアプリケーションフレームワークに分類されるものです。

Webフレームワークは**「Webアプリケーションなどを開発するために必要な機能があらかじめ備えられている開発基盤」**を提供してくれます。これらはベタープラクティスな手法やテストされたライブラリを多数盛り込んでおり「誰でも」一定の品質でアプリケーションを書くことが出来ます。つまり、高品質で生産性の高い開発体験を提供するのがフレームワークの役目です。これらのエコシステムは広く知られており、それらをベースにすることで私たちは事業やそのための開発に集中することができるようになります。

これらの話を十分に理解した上でこの先を読んでください

オレオレFWについて知りたい人はとりあえずこの動画を視てください。

https://www.youtube.com/watch?v=TiyJh6QPork

その上での話ですが、オレオレFWは一般的なWebフレームワークの多くの利点を放棄します。生産性や品質なんて物は制作者に依存しますし、第3者から見ると理解不能な物体が誕生するだけです。知恵袋やStack OverflowでオレオレFWの質問をしても全く回答は返ってきませんし、ChatGPTもまともなことしか答えてくれません。

つまり、令和5年においてオレオレFWを使うモチベーションはゼロです。というか使ってはいけません。Pythonな人ならstarletteやFastAPI、DjangoやFlaskを使うと良いでしょう。

最初にstarletteを持ち出す時点で、私の思想はかなり歪んでいます

オレオレFWを作る利点

オレオレFWは現場においてはほぼアンチパターンですが、趣味の範囲では良いことがたくさんあります。まず、フレームワークを作る中でアプリケーションの組み立て方を学ぶことができます。また、アプリケーションの設計を考えたり既存のフレームワークの目指したかった世界観が理解できるなど良いことがたくさんあります。また、既存フレームワークでは解決できない問題に直面したときに、それらを解決する手段を提案することができるようになります（コラコラ）。

ともかく、Webフレームワークを十分に理解して使いこなすために一度自分で作ってみるというのはエンジニアとして良い経験になると思います。というわけでやっていこう！オレオレFW！

オレオレFWを作った動機

私は研究室でPythonを使ったWeb開発をしています。そもそも、PythonでWebを書くというのは例え既製品のフレームワークを使ったとしてもかなりの地獄が待っています。まず、Pythonはバージョンによってライブラリが壊れやすいことで有名です。Python2 → 3のジャンプを経験した人は色々苦しんだでしょうし、著名ライブラリでもランタイムのバージョンアップにライブラリが追従しない事があり気苦労が多いです。Python3系になってBCは減りましたがメモリ周りの最適化が進む中でJIT依存のライブラリが被害を受けたりは良くあります。

特に機械学習系のライブラリでよく使われるnumbaのランタイムの追従が遅くて苦労した人が多いでしょう

これに対応するためのパッケージ管理手法も中々難しいところがあります。Pythonではnpmやcomposerに匹敵するその言語のパッケージマネージャというものは確立していない印象です。pipのrequiements.txtは管理が手間だし、poetryなど高級な物を使っても結局requirements.txtを吐いたり環境構築が辛いなどの問題があります。

また、検索汚染もかなり深刻です。例えば、sqlalchemyでモデルのupdateを検索すると、ほとんどの例でselect → session commit()という手順を踏んでいます。この場合はDMLが2回走りますが、実際にはupdate1回で良いことは誰でも分かる事です。

この状況の中で、研究室という特殊な環境で持続的な開発を行うためにはかなり気を遣わないといけません。これについては以前のブログでも述べているのでこちらもご覧ください。

https://developers.crowd4u.org/posts/2022-12-24-advent_calendar/

よって、具体的には以下の点を考えて開発を行う必要があります。

ちょっとの修正で3年は生き残るフレームワーク
可能であればORMとかそういう物に頼らず、自分で面倒を見るぞという気になれる設計
ライブラリやランタイムのBCの影響をなるべく受けない設計
フレームワーク特有の魔法に頼らない素朴で分かりやすいコードや設計

これらを考えるとデータベース周りでORMに頼りたくなかったり、ルーターとバリデーションがセットになったようなBaseModelにすらあまりロジックに入ってほしくない、脱出を見込んだ設計にするためにビジネスロジックは標準だけで簡潔させたい…お、これは既存フレームワークだけでは無理なのでは？よし！オレオレだ！という結論になるのは自明だと思います。

典型的な言い訳なので、あなたの周りでこのようなことを言い出した人が居たら冷水をぶっかけましょう

ちょっとの修正で長生きするフレームワークを目指す理由

私たちは基本的に研究の片手間に開発をする必要があります。しかし、Pythonを取り巻く状況は進化のスピードが早くそれに追従し続けなければあっという間に負債になってしまいます。普段からライブラリやランタイムの更新は意識するようにしていますが、万一BCがあったとしても影響範囲を最小限にすることで工数を抑えることができると思っています。

あと、素朴な設計のコードは案外長生きします。ここでいう「素朴」とはなるべく標準ライブラリに寄り添った実装を指します。皆さんも機械学習ブームで盛り上がった2018~2020年頃のCNNで画像識別タスクをやるプログラムを作ったと思います。それを動かしてみてください。多分、動かないと思います（笑）。ベタに変化を急ぐライブラリに手を出すと数年経ったら全く動かなくなります。その一方で、最初に作ったHello Worldのプログラムを動かしてみてください。Python3系の時代に書いた物であれば今でも動くと思います。このような基本的な機能は年月が経っても基本的に壊れることはありません。

つまり、こういう設計を心がけるとランタイムの更新にも追従しやすくなるのです。基本に忠実に基本の組み合わせによって複雑な物を表現したら、それが複雑でも長生きすると思っています。人類、バージョンアップを放棄したらあっという間にレガシーコードが爆誕します。そのために複雑だけど優れた魔法に頼らず、物理でゴリ押すことを選択しています。速度や性能の面で不利になりますが、あとで手を付けにくくなる事は回避したいのが狙いです。

どうです？オレオレしてるでしょ？？？？

さらに言うと、バージョンアップなどをノーコストに近い状態に持っていくことを目指しています。FWはメジャーアップデートするとミドルウェアが大きく変わって修正工数が増えるということがありますが、限られたリソースの中でそういう状況に持っていきたくはないです。パッケージを弄ってテストを回せばバージョンアップはいける！という状態にしたいです。

ORMを使いたくない

Pythonには有名なORMやその拡張としてマイグレーションツールが提供されています。しかし、以前マイグレーションツールを使ったところ偶然サーバーの瞬断が発生していまいテーブルの不整合が生じてしまいました。ALTERテーブルが走った場合は基本的に戻せないので、マイグレーションツールの世代管理周りのズレを素手で修正する事になってしまいました。この時は、こういった問題に対応できるメンバーが居たから何とかなりましたが研究室にこの先そういう人材が来るかは分かりません。その他にもORMはテーブルとモデルが1:1に密結合してしまうような雰囲気を与えたり、今のテーブル設計とユースケースにズレがありORM的な使い方が苦しいという課題があります。

研究室では複数のサービスが運営されており将来的にこれらを統合することが計画されています。それらも考慮するとORMに頼らず自分達でドメイン設計をやっていく気合いを持つ必要があると考えています。そのため、一部ではORMが使われていましたが、一貫性の観点からも全て剥がし切りました。現在は、一部の複雑なクエリにはテンプレートエンジンを使いつつ生SQLを操作する選択を取っています。

ライブラリやフレームワークの魔法に頼らない

個人的にはstarletteやFastAPIの設計が大好きです。これらはシンプルな設計を提供しつつミドルウェアを追加することで複雑な処理も出来るようになります。ただ、ミドルウェアを挟んでしまうと手続き型っぽく何処で何をやっているか追いにくくなってしまいます。大学生は基本的に手続き型プログラミングの世界で生きているので、なるべくその世界の感性で理解できるコードを実装したいと思います。てか、裏で魔法を使わずともif文とかでええやろ！なんで、かっこよくやりたいんや！！

今回作ったオレオレFWについて

今回作成したオレオレFWはこちらに公開しています。このオレオレFWはASGI互換のアプリケーションになっていて、これに対応した様々なワーカーを使って動作させることができます。今回はuvicornを使っています。

https://github.com/notchman8600/ore-1

時間の都合上、POSTのサンプルを提供できていないと思うのでDBから値を取ってそれを表示するだけのシンプルなアプリケーションになっています。

今回のフレームワークは以下のことを目標に設計しています。

放置しても2年は動くであろうライブラリ選定（実績有）
メインアプリケーションの部分はライブラリに頼らない基本設計
1つの処理を一貫性のある作法に基づいて実装できる設計
闇雲に例外キャッチをしようとしたらコードレビューで叱れるエラーハンドリング設計
APMなどの連携をある程度考えたカスタマイズしやすいロギング
静的解析やIDEに優しいソースコード

まあ、設計指針についてはほとんど上で述べた課題に対する答えになっているので特段触れませんがいくつか新しい話があるのでそれに触れておきます。

1つの処理を一貫性のある作法に基づいて実装する設計

フレームワークでは当たり前といえば当たり前ですが、ある種の一貫性のあるやり方で機能を追加できる設計を目指しています。これによって、いわゆるコピペプログラミングをやったとしても一定の制約の範囲に抑えることができて品質を保つことが出来ます。

今回のオレオレFWでは以下の一貫性のある実装を行えるようにしています。

期待したいレスポンスをControllerで定義
そのレスポンスに必要なデータをRepositoryが作成する
Repositoryは必要なデータを取得するために意味のある単位でモデル化されたStoreにフェッチする
ストアは1つ以上のテーブルから意味のあるデータモデルのCRUDを行う

つまり、1機能を追加したいときはControllerに1メソッド、Repositoryに1メソッド、Storeにメソッドがあればそれを使いなければ追加すれば良いです。基本的にこれを繰り返すことで機能を増やしていける設計にすることでコピペプログラミングをやりやすくしています。

コピペプログラミングができるということはCopilotやChatGPTにも優しい設計になっています。人間が理解不能なものはLLMも理解不能です。愚直だけど単純な方が後々幸せになれます。

今回は実装上、他の概念も登場していますがそれは脱出を見込んだ話になっておりControllerからStoreまでは長期にわたって生き残らせる設計にしています。

オレオレFWの紹介

早速ディレクトリ構成を見ていきましょう。今回はこのような構成になっておりappがエントリポイントになっています。

app
- actions/
- controllers/
- dispatchers/
- routers/
- model/
- stores/
- templates/
- main.py
db
- DDLやテストデータの挿入用、気にしなくて良い
…（雑多なファイル）

dispatcherはASGIレイヤーの処理をとなっており、HTTPリクエストを発火させてレスポンスを送信する役割を担っています。本来であればフレームワークに内包されていますが、今回はフレームワークお母さんが存在しないので自前で実装しています。

基本的にはフレームワークお母さんが居ないので自前で作ったに過ぎないレイヤーですが、1点だけ重要な事があります。それは、HTTPのイベントに基づいて動いたアプリケーション処理の例外を全てハンドルする役割です。つまり、アプリケーションのロジックで例外が出た場合、最終的にこのレイヤーで全てハンドルできるようになっています。ここで、エラーログを取得してレスポンスを返せば絶対に白いエラー画面を返さずに済みます。エラーハンドリングを分かっていなくても事故ればログが出るので、何かあったときは後輩を救うことができます（とても大事）。

async def dispatch_http_event(scope: HTTPScope, receive: ASGIReceiveCallable, send: ASGISendCallable) -> None:
    # dispatch errorを全体的に囲むことで白い画面を出さないようにする
    # 本当はAPIコールかHTMLコールかによって例外処理を考える必要がある
    # APIコールであればエラーオブジェクトのJSON、HTMLであればエラーページをレンダリングする必要がある
    try:
        content_type, encoded_res = await http_router(scope, receive)
        # レスポンスヘッダ
        headers = [
            (b"content-type", content_type),
            (b"content-length", str(len(encoded_res)).encode(encoding="utf-8")),
        ]
        await send({"type": "http.response.start", "status": 200, "headers": headers})
        await send({"type": "http.response.body", "body": encoded_res})
    except Exception as e:
        # ここでアプリケーションから上がってくる例外は全てハンドリングする
        logger.error(f"error has occured in http event: {e},{traceback.format_exc()}")

        # HTTPレスポンスの準備
        # ここではエラー起因の白い画面を出さないようにするためにエラーページをレンダリングする
        html_content = render_template("error.jinja2.html", {"message": "hello, I am variable value."})
        await send(
            {
                "type": "http.response.start",
                "status": 500,
                "headers": ((b"content-type", b"text/html"),),
            }
        )
        await send({"body": html_content.encode("utf-8"), "type": "http.response.body"})
    return

Router層（Routers+Actions）の説明

Router層ではリクエストを受け取りそれをバリデーションしてControllerに渡す役割を担います。多くのフレームワークではroutersとactionsを合わせたものが提供されています。例えばFastAPIであればエントリポイントの関数+pydanticを使うことで実現できます。

# ルーターではリクエストを受け取ってアクションを実行しレスポンスを返却する。リクエストやレスポンスの内容はアクションに委譲する
async def http_router(scope: HTTPScope, receive: ASGIReceiveCallable) -> tuple[bytes, bytes]:
    path = scope["path"]
    content_type: list[tuple[bytes, bytes]] = scope["headers"]
    if path == "/":
        hello_action = HelloAction()
        # リクエストボディを受け取る
        body = await receive_body(receive)
        # ヘッダーの解析
        headers = parse_headers(content_type)
        # ボディの中身とcontent-typeを渡す
        return hello_action.run(body=body, headers=headers)
    elif path == "/user" and scope["method"] == "POST":
        # リクエストボディを受け取る
        event = receive()
        return b"application/json", json.dumps({"message": {"message": f"とりあえずPOSTはできたからいい加減な値を返す"}}).encode()
    else:
        # 本当に適当なレスポンスを作成したい時はこのように直接書くこともできる
        return b"application/json", json.dumps({"message": "Not Found"}).encode()

いや～、if文でルーティングなんて誰の影響を受けたのでしょうか？（笑）この形にすれば存在しないエンドポイントを叩いた時に必ず404を返せるので良いでしょ？そして、とにかく分かりやすい（これ大事）。Router層ではリクエストデータやヘッダの取得を行いそれをActionに流しています。ここでは意味のあるデータの形にせず辞書形式のままにしておきます。パースエラーが起きた場合はここで止まる想定です。

多くのフレームワークではrouter.add(”/someroute”,ハンドラ) のようにエンドポイントに対応するハンドラを登録してイベントを定義します。ただ、正直分かりにくくないですか？しかも、既製品だと存在しないパスにアクセスしたときはミドルウェアで例外作って404を返すようにしないと白い画面が出るなど使いづらいところが多いです。この形にすればそういう手間がかからない。しかもミドルウェアを使わないのでシンプル！どうです？オレオレしてますねwww

次にActionです。Actionではbodyやheaderの情報を渡してそれをバリデーションします。バリデーションしたオブジェクトはリクエストのDTOか生データに変換してControllerに渡します。

Actionは基底クラスを定義しています。Action.run()を実行することで実際の処理を開始する制約を与えています。派生クラスではrunだけ実装すれば良いのでとてもシンプルですね（主観）

# Standard Library
from typing import Any

# Actionの基底クラスを定義する
# こいつはほぼ何の役にも立たないが、runを起動するという制約を与えることができるので実装している
class Action:
    def __init__(self, name: str, description: str, args: dict) -> None:
        self.name = name
        self.description = description
        self.args = args

    def run(self, *args: Any) -> tuple[bytes, bytes]:
        raise NotImplementedError("Action.run() must be implemented by subclass")

    def __str__(self) -> str:
        return self.name

    def __repr__(self) -> str:
        return self.name

Actionは原則、1つのエンドポイントに1つ定義します。Actionとエンドポイントを1:1にすることでコードジャンプで追いやすくしています。例えば、GetHelloActionではあればHelloを取ってくるイベント、AddHelloActionであれば何らか”Hello”を追加するのだなと理解しやすくなります。もちろん、RESTに準拠すれば十分という話もありますがコードを読めば大体理解できるということが大事だと思っています。

Actionには名前が付けられるのでエラーログにAction名を叩き込むことでどの処理でエラーが出たか若干分かりやすくなるという話もあります

Actionの実態はこんな感じです。Actionにはルーターでパースしたbodyの文字列が入ってきます。

返り値がtupleですがこれはレスポンスのバイト列とcontent-typeのバイト列を想定しています。普通のFWだとResponseオブジェクトに辞書を入ればいい感じになるので、後述するControllerが返したレスポンスのDTOからバイトデータを作るようにしています。

class HelloAction(Action):
    def __init__(self) -> None:
        super().__init__("hello", "say hello", {"name": "string"})

    def run(self, headers: dict, body: dict) -> tuple[bytes, bytes]:
        # Actionでレスポンスを作成する
        res = controller.get_hello(1)
        content = render_template(
            "index.jinja2.html",
            {
                "message": "hello, I am variable value.",
                "name": res.user_name,
                "greeting": res.greeting,
                "user_id": res.user_id,
            },
        )
        return b"text/html", content.encode()

ここまでのレイヤーは今のASGI準拠の自作FWに深く依存したところになっています。ただ、この辺りの実装は将来的に全て捨てて既製品（FastAPIなど）にスムーズに移行することが可能です。実際、今の現場ではPydanticのBaseModelをさらにDTOに詰め替えることでController以下の互換性を保っています。色々なエコシステムへの脱出が可能でありながら、素朴に実装できるのがオレオレFWのメリットです。引っ越しの際にはファイル数が多いかつActionが1つ1つバラバラになっているので、手間が増えますが1つ1つは単純作業なので工数は読みやすいです。工数の読みやすさは大事で、将来的に改修を依頼したときにスムーズに見積もりを出して発注に至ることもできます（コラコラ）。

Controller層の説明

ControllerではリクエストのDTOを受け取りService（今回は未実装）やRepositoryを呼び出し、レスポンスのDTOを返却する責務を担います。この設計はSpringFrameworkの設計を意識しています。

class UserGreetingDto:
    def __init__(self, user_id: int, user_name: str, greeting: str):
        self.user_id = user_id
        self.user_name = user_name
        self.greeting = greeting

class HelloController:
    def __init__(self) -> None:
        self.hello_repository = HelloRepository()
        pass

    def get_hello(self, user_id: int) -> UserGreetingDto:
        user_greeting = self.hello_repository.get_hello(user_id)
        return UserGreetingDto(user_greeting.user_id, user_greeting.name, user_greeting.greeting)

controller = HelloController()

DTOクラスは全てPythonのclassを使っているので、ライブラリに依存しない世界を実現することができます。また、ランタイムのバージョンアップで壊れることもないので堅牢です。

DTOの定義場所は別のフォルダでも良いですがファイルが散るとちょっとした加工をするときに面倒なのでControllerに置いています。困ったときは移せば良い。

dataclassを使わない理由ですが、主にasdict()を使わせないためです。辞書は強力なデータ表現ですが、何でも入れることができるので可能性が爆発します。すると、せっかくDTOなどで受け渡しされるデータの透明性を確保したのに水の泡になります。強すぎる武器は時に毒になります、それを使わせるのはヤバい。それを防ぐために意図的に使っていません。いや～、オレオレですね（笑）

Repository層の説明

Repository層ではビジネスロジックにおいて意味のあるモデルを作成、取得する責務を担います。

class HelloRepository:
    def __init__(self) -> None:
        self.hello_store = HelloStore()
        self.user_store = UserStore()

    def get_hello(self, user_id: int) -> UserGreeting:
        user = self.user_store.fetch_user(user_id)
        greeting = self.hello_store.get_by_user_id(user_id)
        return UserGreeting(user.user_id, user.user_name, greeting.greeting)

この例ではユーザーの挨拶という1つのモデルをgreetingテーブルとuserテーブルから作成しています。データ作成の例が作れなかった（多分）のですが、登録時はadd_hello的な関数からそれぞれのstoreのsaveメソッド的なものを呼び出す想定になります。ここもサードパーティライブラリには依存していません。この辺りがFWに依存してしまうと本当に他所に脱出できなくなるので辛いんですよね。storeがインフラに依存してしまうのは仕方ないですが、そこまでで抑えてしまえばデータロジックの部分は崩さずにいけます。いや～、便利だな（笑）

これは集約とか言われたりするかもですが、私はそういう高級な考え方は十分理解していません。あくまで複数のテーブルから意味のあるモデルを作るという理解で生きています。

Store層の説明

Store層ではDMLを発行してデータの読み書きを行なうレイヤーになっています。基本的にはテーブルと1:1ですがJOINクエリを使う場合は複数テーブルを扱うこともあります。Store層の呼び出しも基本的にDTOを介して行います。DTOを介することでインフラやライブラリに影響されやすいDB操作を吸収し、他のレイヤーに影響しないようにしています。さらに、基底クラスにインフラ知識を寄せることで派生クラス（実態）についてはノータッチで移行が可能です。

class FetchUserDto:
    def __init__(self, user_id: int, user_name: str):
        self.user_id = user_id
        self.user_name = user_name

class UserStore(Store):
    def __init__(self):
        super().__init__()
        pass

    def fetch_user(self, user_id: int) -> FetchUserDto:
        query = f"SELECT id, user_name FROM users WHERE id = %s"
        row_data = self.fetch_data(query, user_id)
        # ここは本当はまともに例外を投げるべき
        assert row_data is not None and len(row_data) == 1, "error, row_data is None or len(row_data) > 1"
        logger.debug(f"row_data: {row_data}")
        return FetchUserDto(row_data[0][0], row_data[0][1])

    def insert_user(self, user_id: int, user_name: str):
        query = f"INSERT INTO users (id, user_name) VALUES (%s, %s)"
        self.execute(query, (user_id, user_name))

ここでフェッチに失敗した時にAssertErrorの例外を出すようにしています。本当は例外が出たらRepository側で整合性を担保しないといけませんが、今はそのようなことは特にやっていません。そういうのは必要な時に追加すれば良いのです。

Storeクラスはインフラ知識を吸収しつつfetchとexecuteに相当するメソッドを定義しています。基本的にfetchは読み込み、executeはその他を想定しています。

class DatabasePool:
    def __init__(self) -> None:
        # PooledDBを使用してコネクションプールを作成
        self.pool = PooledDB(
            creator=pymysql,  # 使用するDBAPI
            maxconnections=6,  # プールする最大接続数
            host="mysql",
            user="root",
            passwd="password",
            db="ore",
            charset="utf8mb4",
        )

    def get_connection(self):
        return self.pool.connection()

class Store(DatabasePool):
    def __init__(self):
        super().__init__()

    def fetch_data(self, query, data):
        with self.get_connection() as connection:
            with connection.cursor() as cursor:
                cursor.execute(query, data)
                return cursor.fetchall()

    def execute(self, query, data):
        with self.get_connection() as connection:
            with connection.cursor() as cursor:
                cursor.execute(query, data)
                connection.commit()

インフラはPyMySQLに依存していますが、executeとqueryの形を維持しておけば派生クラスへの影響を無くすことができます。インフラ以降の際は基底クラスを弄るだけで済むので現実的な工数で載せ替えが可能になると思っています。いや～、楽ですね…。小噺ですが、今の現場ではライブラリ的に問題のあるライブラリを使っていますが、このような設計にするおかげでスムーズに移行ができそうです。このように常にライブラリから脱出することを見込んだ設計にするのはとても大事だなと実感しています。

idは直で渡していますがこれは要はバランス…（笑）だって、これだけでDTO作るのはそれはそれで面倒でしょう。idで物を引くという極めて多いユースケースに至ってはDTOを使わないというルールを設けてしまえば最初に述べた一貫性も維持できますし、煩わしさも抑制できます。

まとめへ

いや～、オレオレしていたでしょ？とりあえず、このFWの考え方に従えば今の現場における私の課題は解決することが出来ています（大事）。あとはフレームワークを作る中で、既製品の考え方も再確認出来てstarletteは最高！の気分になっています。あと、私はフルスタックフレームワークが余り好きではないので素朴な既製品がより素朴になったなと思うとニヤニヤが止まらないですね。

正直、これをそのまま現場に持ち込んでも同僚の反発は必至です。また、これが大規模になったり、5年後生き残るのか？とか言われたらそれな…という話になります。ただ、随所でクリティカルなケースを考えてそれの脱出を見込んだ設計を心がけてるあたり、そういう気配りとシンプルを積み重ねた物があればある程度は何とかなるのではないでしょうか？

オレオレを現場に投入したい方へ

それは家庭菜園でやれ！、以上！

まあ、世の中綺麗事では通らないこともあるからな…。ただ、実戦テストを通じていない物を投入すると本当にヤバいので止めた方が良いと思います。今回のオレオレFWも自分が今まで様々に開発したり現場に投入して2年近く…（フィクションです）使った実績を元に、今作るならこうするという考えを述べているものです。私は経験の浅いエンジニアですが、それでも数年間取り組んだ成果として半年くらいは何とかなるオレオレFWになっています。

まあ、その上で用量用法を守って同僚を酒や食事で口説き落として部分的にオレオレを使って成果を出して納得していただく…というのが個人的にオススメのオレオレの普及方法です。オレオレFWが現場で機能したら1人のエンジニアとしてちょっと嬉しいですよね（笑）

ただ、最後は何で作るかより何を作るかですよ？手段に捕らわれ過ぎるのは良くない。私たちは事業課題を捉えてそれを技術で解決するプロなのですから…

真実のまとめ

いや～、最近はとある現場に思う事が多々ありすぎまして…。まあ、世の中は様々に様々ですが皆さん強く生きていきましょう。現実を捉えて課題を解決する地道な積み重ねをしていけばきっと人生は良き物になると思います。そう信じて、私はけもの道を歩み続けます…。

来年のクリスマスイブはせめて1人温泉でゆっくり…なんて事を思っています。では、外は寒いですが独りぼっちのクリスマスイブを強く生きてください。

ここから先は真実をお伝えします

今年のSOHO祭（架空のイベント）に合わせて爆誕した真実のサイトを研究室のメンバーと作成しました。このサイトはとにかく軽量で必要な情報をミニマムに提供することを目指しています。機能は「ブース一覧」「エリア別フィルタ」「ステージスケジュールのカレンダー（ical互換）」の3つです。

シン・SOHO祭 TOP

ちなみにロゴの色ですが#FF7E1Cと#00ACD1を使っています。これには明確な意図がある色で、決してとあるサイトのロゴを参考にしている物ではありません。これが分かる人は私と仲良くなれると思うのでDMをください（笑）

ソースコードはこちらで公開しています。見て分かると思いますが、HTML,CSS,JSのシンプルな作りになっています。何で作るのではなく、何を作るかが大事ですよね？必要な人に必要な機能が提供できれば、技術スタックなんてどうでもいいんですよ。

https://github.com/halca-crowd/soho-Illuminati

なお、PageSpeed Insightのスコアは何処かのサイトと比べて遙かに好成績をマークしています。GAを入れたせいで若干数値が悪くなっていますが、これを抜くとオール100に近いスコアをマークしました。来年以降も気が向いたら真実をお伝えする予定なので、こちらのアカウントもよろしくお願いします。

soho-Illuminati (@soho_illuminati) on X

このサイト制作ではスクラムを実践した開発を行ない、なんと8時間で0からサイトを立ち上げることが出来ました。このサイト制作で培われたスクラムのノウハウについては、いずれ何処かでお話しようと思います。以上、SOHO祭の真実でした。皆さん、よいお年をお迎えください。

マチアプの今年の戦績ですが13戦0勝、3サービスBANでした。対戦ありがとうございました。これさ、本気でそういう出会いを求めるときにオレオレFW以上のけもの道になるのでは？まず、手段が断たれているので詰みなんだよね（笑）以上、notch_manの真実をお伝えしました。私は一人イブの夜の街に消えます。

VPC PeeringとALBのバーチャルホストで環境の切り分けとコスト削減を両立させる

2023-10-30T10:05:00Z

はじめに

NextCrowd4U(N4U)では様々なタスクの実行を可能にするためにOpenAIのAPIやGoogleSearchAPIを使用する機能の提供をしています。

これらの機能はN4U本体とは独立したもののためN4Uとは別のリソース(EC2やECSだけでなくVPCなども別です)として立てています。

今回はALBが高くて新しく立てたくないという話と、ALBが存在しないVPCに新規サーバーを建てる際にVPCのためピアリングを使用して、ALBに導線をつなぎバーチャルホストとして立てたという内容を書いていきます。

今回作成する環境

まず、今回開発したものについて触れておきます。ザックリ言うと、OpenAIのAPIをたたき、N4U本体に返すような踏み台的な環境を作成しました。イメージとしては下の図のようなものになっております。

以下の様な構成で、VPCピアリングを使用し、別のVPCで使用しているALBをバーチャルホストで使用する、という形での実装を今しています。

API Gatewayを使用しなかった理由としては、Streamをするような設定が面倒だったためですね。。。

このような面倒なことをした理由を書いた上で、具体的な実装についてTerraformを使用して紹介していきます。

理由：ELB,高い・・・

私たちの開発チームは毎月80USD程度のコストをELBに使用しています。（ELBの料金体系に関してはこちらの公式ページを参照してください。）

合計で5つのELBが立っていますが、そのうち2つはほとんどトラフィックがないNLB（そのため金額はほぼ掛かっていない）で、残りの3つのALBがこのコストのほとんどの割合を占めています。

LLMAPIも今後研究の実験で何度もトラフィックが発生することが分かっているため、ALBの料金が当然ネックになってきます。

一つのALBで可能な限り処理すれば、少なくとも時間当たりの料金が新しく作成するよりも削減することが出来ると踏み、今回の構成にしました。

実装

実際に今回作成したIaCの一部を紹介していきます(このままコピー＆ペーストしても動きませんので注意してください)。各リソースは直書きにしていますが、適宜tfvarsで管理したりSecrets Managerを使用したものにするなどして対応してください。

VPC ピアリング

今回のケースとして、「本番VPCとその上にVPCが作成されており、新しくFargateを立てるVPCは存在しない」というものだったため、新規でVPCを作成し、ピアリングの設定を行います。

VPCの作成
- CIDRブロックは適当に書いていますので環境に応じて書き換えてください。

resource "aws_vpc" "hoge-vpc" {
  tags = {
    Name = "hoge-vpc"
  }
  cidr_block = "0.0.0.0/16"
}

VPC上にパブリックサブネットを2つ作成します。

resource "aws_subnet" "hoge-subnet-1"{
    vpc_id = aws_vpc.hoge-vpc.id
    cidr_block = "0.0.0.0/24"
    availability_zone = "ap-northeast-1a"
    map_public_ip_on_launch = true
}

resource "aws_subnet" "hoge-subnet-2"{
    vpc_id = aws_vpc.hoge-vpc.id
    cidr_block = "0.0.1.0/24"
    availability_zone = "ap-northeast-1c"
    map_public_ip_on_launch = true
}

インターネットゲートウェイも続けて作成します。

resource "aws_internet_gateway" "hoge-internet-gateway" {
  vpc_id = aws_vpc.hoge-vpc.id
}

最後に、ピアリングのためにルートテーブルとルートを作成します。

prod-vpc → hoge-vpcとhoge-vpc → prod-vpcの両方について接続の設定をしていきます。

ルートテーブルの設定を間違えると接続がうまく行きませんので、よく確認しながら設定を行ってください。

# ルートテーブルの作成
resource "aws_route_table" "hoge_to_prod-route-table" {
  vpc_id = aws_vpc.hoge-vpc.id

  tags = {
    Name = "hoge_to_prod-route-table"
  }
}

# ルートの作成
resource "aws_route" "hoge_to_prod_route" {
  route_table_id = aws_route_table.hoge_to_prod-route-table.id
  destination_cidr_block = data.aws_vpc.prod-vpc.cidr_block
  vpc_peering_connection_id = aws_vpc_peering_connection.hoge_to_prod.id
}

resource "aws_route" "prod_to_hoge_route" {
  route_table_id = data.aws_route_table.prod-route-table.id
  destination_cidr_block = aws_vpc.hoge-vpc.cidr_block
  vpc_peering_connection_id = aws_vpc_peering_connection.hoge_to_prod.id
}

resource "aws_route" "hoge_to_internet_route" {
  route_table_id = aws_route_table.hoge_to_prod-route-table.id
  destination_cidr_block = "0.0.0.0/0"
  gateway_id = aws_internet_gateway.hoge-internet-gateway.id
}

# ルートテーブルの関連付け
resource "aws_route_table_association" "hoge-route-table-association-1" {
  subnet_id = aws_subnet.hoge-subnet-1.id
  route_table_id = aws_route_table.hoge_to_prod-route-table.id

  depends_on = [ aws_route_table.hoge_to_prod-route-table ]
}

resource "aws_route_table_association" "hoge-route-table-association-2" {
  subnet_id = aws_subnet.hoge-subnet-2.id
  route_table_id = aws_route_table.hoge_to_prod-route-table.id
  
  depends_on = [ aws_route_table.n4u_hoge_to_prod-route-table ]
}

resource "aws_vpc_peering_connection" "external_to_prod" {
  vpc_id = aws_vpc.hoge-vpc.id
  peer_vpc_id = data.aws_vpc.huga-vpc.id
  auto_accept = true

  tags = {
    Name = "hogehuga-peer"
  }
}

Fargate SPOTの作成

次に、ALBがないVPC側でFargateを構築します。今回はSPOTインスタンスを使用するため、capacity_providerに関しても設定の必要があります。

Fargateのタスク定義は省略しますが、環境に応じて作成してください。

クラスタの作成

resource "aws_ecs_cluster" "hoge-cluster" {
  name = "hoge"
}

サービスの作成
- コンテナのポートに関しても環境に応じて書き換えてください。

resource "aws_ecs_service" "hoge-api" {
  name = "hoge-api"
  cluster = var.ecs_cluster
  task_definition = aws_ecs_task_definition.hoge-api-aws_ecs_task_definition.arn
  desired_count = 1

  capacity_provider_strategy {
    capacity_provider = "FARGATE_SPOT"
    weight = 1
  }

  network_configuration {
    assign_public_ip = true
    subnets = ["subnet-hogehuga", "subnet-piyohoge"]
    security_groups = ["sg-hogehugapiyo"]
  }

  load_balancer {
    target_group_arn = aws_lb_target_group.hoge-api-tg.arn
    container_name = "hoge"
    container_port = <your port>
  }

}

最後に、お好みでタスクを作成するコードを書いていただければ完成です。

以上のコードをterraform applyすることで、VPCピアリングをして他のVPC上のALBに接続することが出来ます。

最後に

作成時に困った点としては、ルートテーブルの知見が少なく、正しくルートが設定されていないことに起因して接続がうまく行かないことでした。もしVPCピアリングを使用してインフラ構築をするときに接続がうまく行かない場合、ルート周りから調べていくと良いのかなと今回の経験を通じて感じました。

今回はほぼIaCの紹介という形になってしまいましたが、ここまでお付き合いいただきありがとうございました！

ﾜﾀｼ、ﾗﾑﾀﾞ、ﾜｶﾗﾅｲ

2023-08-10T04:09:24Z

はじめに

ふざけたタイトルで始めましたが、とあるシステムを移植する際に発生した問題、結局どうしたかについて書いていきます。最初に感想を話すと、「知見がなさすぎる、ﾂﾗｲ」です(もっと勉強しないとなぁ…)。

さて、事の発端は現行のNextCrowd4U(N4U)に以下のような状況が発生していることです。

N4Uに依存している訳ではないが、N4Uの環境に共存しているシステムが存在している
現状は問題ないが、今後の機能実装の際に本番環境のリソースを圧迫する可能性がある

以上の理由から当該システムをN4Uから切り離すこと、また当然ながら研究費は限られていますからできる限り低コストで移行する必要がありました。

すぐにできそうかなと思っていたのですが、結果何もわからず1か月くらい格闘することになったので書いていこうと思います。

図が大雑把なのはご愛敬と思いながら読んでいただけると幸いです。

前提条件

切り離しの際にいくつかの前提条件がありましたんので最初にまとめておきます。

Goで実装されたAPI
システムの内部処理で外部API(Google Search API)を使用している
Search APIのリソース削減のため、Memcachedを使用している
- 検索結果をキャッシュして同一の検索クエリに対してAPIを使用せずに結果を返すようにしている

これに加え、コストをできるだけ低くするという制約が存在しています。

①おれのかんがえた最強の構成

最初に考えたのは以下のような構成です。

ElastiCache(Memcached)と接続するためにLambdaをVPC内に配置しています。

LambdaはGoに対応しているので、Lambdaでシステムを実行し、APIGatewayでAPIを立てるのが一番良いのかなという話です。

しかし、この構成には問題点が存在し破綻しました。

Lambdaが外部サービスと通信できない

一か月ほど格闘した主な理由はこれに気づくのに時間がかかりすぎた事です。

そもそもGoのソースをLambdaで使えるように変えていなかったみたいなゴタゴタがありながらも、デプロイがうまく行かなかった際に主にうまく行かなかった理由は以下の2点でした。

ElastiCacheとからレスポンスが返ってこない
Search APIにリクエストを投げることが出来ない

1に関してはアウトバウンドルールの設定が間違っていたことが原因で解決にそこまで時間はかかりませんでした。

問題は2で、セキュリティグループですべての通信を許可するように設定しても通信が上手くいかないところまでは分かっていたのですが、だからこそIAM Roleやソースコード側に原因があると思い込み、先輩に指摘されるまでVPCはじめネットワーク周りの調査を全然してませんでした。

先輩の指摘後、改めて調査すると以下の記事を見つけました。

VPC LambdaはIGWからインターネットに出られないわけではなかったという話 | DevelopersIO

なんと、VPC LambdaはパブリックIPを持たないらしい。。。

自分でも検証してみましたが「なかった」。外部と通信できないのはそれはそうという感じですね()

つまり以下の現象が本構成でシステムを実装する際に発生しています。

ElastiCacheと接続するためにLambdaはVPC内に配置する必要がある
しかし、VPC LambdaはパブリックIPを持たないため外部と通信できない

これの対応方法として、

NAT Gatewayを利用する
Lambdaをあきらめる

という2つの方法が存在します。実際に採用した構成を次節で紹介します。

②実際に採用した構成

最終的に、1のNAT Gatewayを利用するコストと2のECS(Elastic Container Service)やElastic BeanStalkなどを利用するコストを検討した結果、以下の4つの理由から後者の選択肢(ECS Fargate)を選びました

STGの際に使用したことがある
常に使うシステムではないため使わない時は停止しておきたい
軽いシステムなので大してvCPUやメモリを消費しない(最小設定で実行可能)
2・3の理由からNATを使用するよりコストは抑えられる可能性が高い

ここからはSTG環境で使用したタスク定義ファイルを一部使いまわしながら、サクッと実装することが出来ました。

また、AWSのコストを$200減らすために行ったことでも紹介した通り、ECRのライフサイクルポリシーの設定やSpotインスタンスの採用を行っています。

出来ました！で終わってしまうのもテックブログとして微妙ですが何はともあれ以上の構成で無事にシステムの移行を行うことで出来ました。

終わりに

今回のタスクをこなす際の感想は最初に書いた通り、AWSやインフラ全般に対する経験や知識量の不足から詰まる事が多かったなという印象です。

純粋な力不足から何もない所で転びがちだったと思うので、知識経験ともに増やしていきたいなと強く思った次第です。

AWSのコストを$200減らすために行ったこと

2023-08-04T05:59:26Z

はじめに

NextCrowd4uの開発に当たり、STAGING環境の整備や為替レートの上昇に伴い、AWSの利用料が4月時点で700USDを越えてしまいました。

主にSTAGING環境の調整を行い400～500USDまで下げたので行ったことについて紹介していきます。

1. 余計なリソースの削除

定番ですが、余計なリソースの削除です。以下の不要なリソースを削除していきました。

使用していないEC2インスタンス
1つでいいのになぜか2つ立っていたECSタスク
たまりまくったECRのイメージ

ECRイメージに関しては、使用していない5日以上作成してから立っているコンテナを削除するようなライフサイクルポリシーを作成し、定期的にクリーニングするようにしました。

2. STAGING環境の改善

①FargateのSpotインスタンス化

Fargate SpotとはAWS公式ブログ(7/27参照)では以下のような説明をされています。

Fargate SpotはAWS Fargateの新しい機能です。中断に強いAmazon Elastic Container Service (Amazon ECS)タスクに最適であり、Fargate価格から最大70%割引で提供します。 (中略) Fargate Spotは、AWSクラウドの空きキャパシティを活用してタスクを実行します。Fargate Spotが空きキャパシティを確保できるかぎり、ユーザーは指定したタスクを起動することができます。AWSにキャパシティが必要になったとき、Fargate Spotで稼働するタスクは2分前の通知とともに中断されることになります。Fargate Spot用のキャパシティが使用できなくなると、Fargateは稼働中の通常のタスクを保持しながら、Fargate Spotで稼働するタスクをスケールダウンします。

AWSの空きリソースを使用することで安く利用することが出来るとのことです。実際に金額を比較してみると(2023/07/27時点)、

	Fargate	Fargate Spot
vCPU(1時間当たりのUSD)	0.05056	0.015168
Memory(1時間当たりのUSD)	0.00553	0.001659

とかなり安いことが分かります。

STAGING環境であるという点や、Spotインスタンスが使えなくなった場合、通常のFargateに移行するような設定も可能なことからSpotインスタンスの導入を行いました。

②タイムスケーリングの導入

当然、STAGING環境は誰も使用しないような時間が存在します。

そのため開発メンバーが作業しない時間帯はFargateの実行タスクを0にすることでダウンさせるようにしました。

実現の方法としてAWS CLIで設定する方法や、EventBridgeとLambdaで実行する方法がありますが、今回はAWS CLIを使用する方法で実行しました。（AWSマネジメントコンソールで確認できないのつらい。。。）

以下のようなCronで、実行タスクを0にする設定と実行タスクを1以上にする設定をCLIで仕込むことでタイムスケーリングの設定をすることが可能です。

aws application-autoscaling put-scheduled-action --service-namespace ecs --resource-id service/{クラスタ名}/{サービス名} --scheduled-action-name {スケジュール名(schedule-onなど)} --schedule "cron({Scaling Time})" --scalable-dimension ecs:service:DesiredCount --scalable-target-action MinCapacity=0,MaxCapacity=0

設定した時間を確認したい場合は以下のコマンドで実行できます。

aws application-autoscaling describe-scheduled-actions --service-namespace ecs --resource-id service/{クラスタ名}/{サービス名}

削除する場合はリソースとスケジュール名を入力することで実行することが可能です。

aws application-autoscaling delete-scheduled-action --service-namespace ecs --resource-id service/{クラスタ}/{サービス名} --scheduled-action-name {スケジュール名} --scalable-dimension ecs:service:DesiredCount

おわりに

まだ考えられるコスト軽減策はあるかと思いますが、今回は主にFargateのタイムスケールについて書いてきました。

実際に以上の対策の実行後、一日当たりのFargateのコストが明らかに減少しました。

今後、Fargateは更に活用していくことになると思うので、コスト面では気をつけつつ、使いこなしていきたいなと思っています！

ここまで読んでいただきありがとうございました。

M1とWSL両方で動作するJupyterLabのDockerファイルを作った話

2023-02-16T07:32:38Z

はじめに

融合知能デザイン研究室でもB3向けのプレゼミが始まり、先生や先輩も環境を再現しやすくするためにDockerでコンテナ立てるかーと思い至りました。

そのため、研究室のPC(M1)と自分のPC(Ubuntu on WSL2)の両方でPython, 特にJupyterLabが動作するようなコンテナを作ったので紹介していきます。

この記事で扱うもの

DockerコンテナのPython3.10イメージでJupyterLabをインストールする方法
Dockerで立ち上げたJupyterLabをブラウザで見る方法

この記事で扱わないもの

JupyterLabイメージをはじめから使用してコンテナを立ち上げる方法
JupyterLabの設定ファイルを最初から適応する方法
PyTorchなどの機械学習ライブラリやGPUをDockerで動かす方法

ファイル構成

以下のようなファイル構成で作成を行います。

.
│  docker-compose.yml
│  Dockerfile
│  requirements.txt
│
└─app
    └─src

requirements.txt

JupyterLabだけ記述していきます。

これだけならDockerfileに直接書けばいいのですが、実際は他にもライブラリを入れるので。。

jupyterlab

Dockerfile

早速Dockerfileを記述していきます。

FROM python:3.10-slim

ENV PYTHONBURRERED=1

WORKDIR /usr/src/app

# python & gcc settings
RUN apt update && apt install -y \
    tzdata \
&& apt-get install -y curl \
&& apt-get install -y gcc \
&&  ln -sf /usr/share/zoneinfo/Asia/Tokyo /etc/localtime \
&&  apt-get clean \
&&  rm -rf /var/lib/apt/lists/*

COPY requirements.txt .

RUN pip install --upgrade pip
RUN pip install --upgrade setuptools

# cargo settings
ENV RUST_HOME /usr/local/lib/rust
ENV RUSTUP_HOME ${RUST_HOME}/rustup
ENV CARGO_HOME ${RUST_HOME}/cargo
RUN mkdir /usr/local/lib/rust && \
    chmod 0755 $RUST_HOME
RUN curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs > ${RUST_HOME}/rustup.sh \
    && chmod +x ${RUST_HOME}/rustup.sh \
    && ${RUST_HOME}/rustup.sh -y --default-toolchain nightly --no-modify-path
ENV PATH $PATH:$CARGO_HOME/bin

RUN pip install -r requirements.txt

# 8000番ポートでトークンなしでJupyterLabを起動する
CMD ["jupyter", "lab", "--port", "8000", "--allow-root", "--ip=0.0.0.0", "--LabApp.token=''"]

M1やWSLでjupyterlabの起動を行うため、以下の設定を行っています。

gccのインストール
cargoのインストール
- そのためのcurlのインストール
- cargoのパスを通すための設定

以上の処理を行った後、8000番ポートでjupyterlabを起動しています。

トークンを発行するとブラウザからアクセスが出来なかったので、トークンなしでの起動をしています。

docker-compose.yml

version: "3.9"

services:
  app:
    build:
      context: .
      dockerfile: Dockerfile
    ports:
      - 8000:8000
    tty: true
    volumes:
      - ./app:/usr/src/app

docker-composeでは先ほど作成したDockerfileを指定して、8000番ポートを使うようにしているだけです。

起動

お馴染みのコマンドを入力して起動します。

docker-compose build
docker-compose up -d

localhost:8000にブラウザでアクセスするとJupyterLabにアクセスできます！

参考

https://c-a-p-engineer.github.io/tech/2022/09/29/docker-rust-install/

Deta.shでサクッとウェブアプリをデプロイしてみる

2022-12-31T15:00:00Z

注意

Deta.shは2023年5月末でサービスを終了し、DetaSpaceへの移行を行いました。これにより、本記事と同様の方法でのデプロイは出来なくなり、利用者もDeta Spaceへのアカウントを持たないとサービスへアクセスができない仕様になりましたので注意してください。

はじめに

昨年、今までアプリケーションの運用ができるPaaS(Platform as a Service)の一つであるHerokuが無料プランを廃止し、代替手段を探すエンジニア(特に学生)が続出しました。私もそのうちの一人なわけですが、代替サービスでたまに聞くようになったDeta.shが面白そうだったので、サクッとアプリ作成からデプロイまでやってみようと思います。

Deta.shとは

Deta.sh(https://www.deta.sh/)は完全無料のホスティングサービスの一つで、以下の3つのサービスを提供しています。

Deta Micros: デプロイサービス
Deta Base: NoSQLデータベース
Deta Drive: ファイルストレージ

Deta Microsに関してはPythonとNode.jsで書かれたアプリのデプロイができるようですね。

早速アプリを作ってみる

というわけで、早速Deta Microsを使ってアプリをデプロイしていこうと思います。 Detaアカウントは作成済という前提で説明していきます。

Deta CLIのインストール

Detaアカウントを作成したら、ローカルからDeta Microsへデプロイを行ったりMicro上のプログラムのcron等が出来るDeta CLIをインストールしていきます。

WindowsであればPowershellで、以下のコマンドを入力します。

iwr https://get.deta.dev/cli.ps1 -useb | iex

Mac, Linuxであればターミナルで、以下のコマンドを実行するとインストールされます。

curl -fsSL https://get.deta.dev/cli.sh | sh

インストールが終了したら、自身の持つユーザーアカウントにデプロイを行うために、ターミナルからログインコマンドを入力します。

deta login

コマンド入力後、ブラウザが自動で開きログインを求められます。 detaコマンドがないと言われた場合は、ターミナルの再起動やパスの設定を適宜行ってください。

アプリケーションを作る

デプロイするためのアプリケーションを作っていきます。正月ということで、運勢を返すだけのおみくじアプリでも作ってみましょうかね。。。

今回は以下の環境でアプリを作っていきます。

Python3.9
- FastAPI
HTML
- Jinja2
CSS
- Bootstrap5

Deta.shがFastAPIのスポンサーらしく、FastAPIにチュートリアルが存在しますので参考にしていきます。最終的なディレクトリ構成は以下の様になりました。

.
├── main.py
├── requirements.txt
└── template
    ├── index.html
    └── result.html

まずは作業ディレクトリをつくり、templateフォルダを作り、その中にトップページのindex.htmlとおみくじの結果を表示するresult.htmlを作ります。

HTMLは以下のように作成しました。

index.html: トップページ

<!DOCTYPE html>
<html>
    <head>
        <link href="https://cdn.jsdelivr.net/npm/bootstrap@5.0.2/dist/css/bootstrap.min.css" rel="stylesheet" integrity="sha384-EVSTQN3/azprG1Anm3QDgpJLIm9Nao0Yz1ztcQTwFspd3yD65VohhpuuCOmLASjC" crossorigin="anonymous">
        <script src="https://cdn.jsdelivr.net/npm/bootstrap@5.0.2/dist/js/bootstrap.bundle.min.js" integrity="sha384-MrcW6ZMFYlzcLA8Nl+NtUVF0sA7MsXsP1UyJoMp4YLEuNSfAP+JcXn/tWtIaxVXM" crossorigin="anonymous"></script>
        <title>Deta.sh-Tryout</title>
    </head>
    <body>
        <h1 class="bg-danger text-white"><a href="/" class="text-decoration-none text-white">おみくじ</a></h1>
            <div class="card mx-auto" style="width: 75%; height: 50%;">
            <div class="card-body">
                <form  action="result" method="POST">
                    <button type="submit" style="width: 80%; height: 18rem" class="btn btn-danger mx-auto d-flex justify-content-center"><h2>おみくじを引く！</h2></button>
                </form>
            </div>
            </div>
    </body>
</html>

result.html: 結果ページ

<!DOCTYPE html>
<html>
    <head>
        <link href="https://cdn.jsdelivr.net/npm/bootstrap@5.0.2/dist/css/bootstrap.min.css" rel="stylesheet" integrity="sha384-EVSTQN3/azprG1Anm3QDgpJLIm9Nao0Yz1ztcQTwFspd3yD65VohhpuuCOmLASjC" crossorigin="anonymous">
        <script src="https://cdn.jsdelivr.net/npm/bootstrap@5.0.2/dist/js/bootstrap.bundle.min.js" integrity="sha384-MrcW6ZMFYlzcLA8Nl+NtUVF0sA7MsXsP1UyJoMp4YLEuNSfAP+JcXn/tWtIaxVXM" crossorigin="anonymous"></script>
        <title>あなたの運勢</title>
    </head>
    <body>
        <h1 class="bg-danger text-white"><a href="/" class="text-decoration-none text-white">おみくじ</a></h1>
            <div class="card mx-auto" style="width: 75%; height: 50%;">
            <div class="card-body">
                <p>ボタンをもう一度クリックするともう一度実行するよ！</p>
                <form  action="/result" method="POST">
                    <button type="submit" data-html="true" style="width: 80%; height: 18rem" class="btn btn-danger mx-auto d-flex justify-content-center text-nowrap">
                        <h2></h2>
                    </button>
                </form>
            </div>
            </div>
    </body>
</html>

result.htmlの15行目、``にはFastAPIから渡された文字列が挿入されます。

次に、FastAPIでサーバーを立てるためのmain.pyを作業ディレクトリ直下に作成し、以下のようにします。

from fastapi import FastAPI, Request
from fastapi.responses import HTMLResponse
from fastapi.staticfiles import StaticFiles
from fastapi.templating import Jinja2Templates
import random

# FastAPIの呼び出し
app = FastAPI()
# Jinja2テンプレートを使用するためにテンプレートディレクトリを指定して呼び出し
templates = Jinja2Templates(directory="template")

# Topページのテンプレートを返す
@app.get("/", response_class=HTMLResponse)
async def index(request:Request):
    return templates.TemplateResponse("index.html", {"request":request})

# ボタンが押された際に結果画面に遷移する
@app.post("/result", response_class=HTMLResponse)
async def result(request:Request):
    # おみくじの運勢リストを作成
    lack_list = ["大吉", "吉", "中吉", "小吉", "末吉", "凶", "大凶"]
    # リストの要素をシャッフルする
    random.shuffle(lack_list)
    # シャッフル後に0番目の要素をおみくじの運勢として返す
    lack = lack_list[0]
    return templates.TemplateResponse("result.html", {"request":request, "lack":lack})

Detaにデプロイ

ここまで書けたらDetaにデプロイしてみましょう！
以下のコマンドを順番に入力していきます。必ずターミナルでは作業ディレクトリを開いた状態にしておいてください。

deta上でインストールするパッケージを指定するために作業ディレクトリ直下にrequirements.txtを作成する

今回はrequirements.txtを以下のようにしました。 Numpyなどの他のライブラリも、テキストファイル上に記載することでインストールできそうですね。
```
fastapi == 0.85.1
jinja2 == 3.1.2
```
このコマンドを打った後、以下のような出力が表示されます。
```
{
    "name": {アプリケーションの名前},
    "id": {Deta MicrosのID},
    "project": {プロジェクトID},
    "runtime": "python3.9",
    "endpoint": {アプリケーションのURL},
    "region": "ap-southeast-1",
    "visor": "disabled",
    "http_auth": "disabled"
}
```
これが作成したアプリケーションの情報で、deta detailsコマンドでも確認することが出来ます。

この出力のendpointの欄に記載されているのが、デプロイしたアプリケーションのURLとなります。
アプリケーションをDeta上に作成する

以下の様にコマンドを入力します。
```
deta new
```
detaのvisorを有効にします

アプリケーションの作成した後だと、HTTPS通信のためのポート開放が行われておらず、アプリケーションにアクセスしてもエラーを返すことがあります。

Detaでは、visorと呼ばれる機能を有効化することで、アプリにアクセスできるようにしてくれるようです。
```
deta visor enable
```
Detaにデプロイする

ここまで来たらついにデプロイです！

オンラインダッシュボード上での煩雑な設定とかもなしに3行でデプロイできてしまいます。すごく便利ですね。。。

捕捉ですが、バグや新機能の実装後もこのコマンドを実行することで最新のアプリケーションをデプロイすることが出来ます。
アプリにアクセスして確認する

早速、1で確認したURLにアクセスして結果を確認してみましょう！

私の場合は以下のリンクにデプロイされています。

https://y0rcw0.deta.dev

無事デプロイできていそうです！

以上がDeta.shを使ってウェブアプリをデプロイする方法です。

ちなみにDeta.shはウェブダッシュボードでサブドメインを設定することが出来るので、使われていなければ自分のアプリに合ったドメインを設定することも可能です。

今回作ったアプリケーションは以下のURLからも確認することが出来ます。

https://omikuji-n4u.deta.dev

おわりに

サクッとと言いつつ、少々長くなってしまった気もしますが、ここまで読んでいただきありがとうございました！

今回紹介したDeta.shは細かい機能不足などはあると思いますが、個人で制作した簡単なアプリを公開するにはかなり便利に感じました。

Deta.shのサイトを読んでいると、今後も無料でサービスを提供するらしいので、もしかしたら個人的に長いお付き合いになるかもしれません(笑)

おまけ

幣開発チームのリーダーが今回作成したアプリを試してくれたらしいのですが、このようなスクショが送られてきました笑

ま、まぁこれ以上悪くならないという意味でもあるので。。。(震え)

参考

"Deta Docs"：https://docs.deta.sh/docs/home/
"Detaにデプロイ": https://fastapi.tiangolo.com/ja/deployment/deta/?h=deta

GitHub ActionsではじめてのCI/CD

2022-12-31T01:00:41Z

Introduction

GitHub Actions ってよく聞くけどわかってないので使ってみたいと思っていました．また，CI/CDについても同様でした．そこで，ポートフォリオサイトのデプロイを題材にGitHub Actionsに触れてみようと考えました．その過程で得た情報を記事にします．

GitHub Actionsで出来ること/やりたいこと

GitHub Actionsとは何か？GitHub Actionsのドキュメントの冒頭が分かりやすく説明してくれていましたのでそのまま引用します．

GitHub Actions は、ビルド、テスト、デプロイのパイプラインを自動化できる継続的インテグレーションと継続的デリバリー (CI/CD) のプラットフォームです。リポジトリに対するすべての pull request をビルドしてテストしたり、マージされた pull request を運用環境にデプロイしたりするワークフローを作成できます。

GitHub Actionsを理解する - GitHub Docsより

今回，GitHub Actionsで行いたいことは以下の２つです．

Hugoのビルド
ビルドしたポートフォリオサイトのデプロイ

手元にHugoを利用したポートフォリオサイトのプロジェクトがあります．（ポートフォリオサイトの詳細はこちらの記事に：Hugoでポートフォリオサイトを作成する際の備忘録）

これをローカルでビルドして，出力されたものをGitHubのリモートレポジトリにpushするだけでGitHub Pagesとして公開することは可能です．しかし，その方法だとサイト更新のたびにコミットログが大量の生成ファイルで埋め尽くされてしまい，見づらくなってしまいます．手元でビルド専用のブランチを切って作業することも可能ですが，面倒なのでこのプロセスを自動化したいと思いました．

というわけで，Hugoのビルド，デプロイをGitHub Actionsで自動化したいと思います．次節からGitHub Actionsの説明，設定を順に行います．

Workflowの定義

WorkflowはGitHub Actionsにおいて実行するジョブの集合で，ブランチのプッシュなどのイベントに応じて発火させることができます．Workflowはレポジトリ内の.github/workflows ディレクトリにYAMLファイルで記述します．

今回は.github/workflows/hugo-deploy.yml を作成し， name を設定ました．これは任意で，無かったら自動的に決まるそうです．

name: hugo-deploy

もう１つ，任意の要素として run-name があります．例えとして不適切かもしれませんが， name と run-name はDockerにおけるイメージ名とコンテナ名に対応する概念です． run-name は式を含むことが可能で，動的に設定することが可能みたいです．（コンテキストの話になるのでこの記事では省略）

Workflow発火条件の定義

Workflow内の on 要素にWorkflowの発火条件を記述できます．今回は master ブランチにpushした際に発火させたいので，以下のように記述します．

on:
  push:
  	branches:
  	  - master

branches 以下を省略すれば，全てのブランチにpushされた際に発火させることができます．

また，push時以外にも発火させることができます．（参考：ワークフローをトリガーするイベント - GitHub Docs）

複数のイベントを条件に発火させることもできるようです．具体的には，複数のイベントが同時に発火した場合，それぞれにWorkflowが実行されるらしいです．

Jobの定義

今回実行したい以下の２つの一連の流れをjobとして定義します．

Hugoのビルド
ビルドしたポートフォリオサイトのデプロイ

上記２つのコマンドについて記述する前にjob全体の定義で設定すべきことがいくつかあります．

jobs:
  deploy-hugo:
  	runs-on: ubuntu-latest
  	steps:
  	  - uses: actions/checkout@v3
  	  	with:
  	  	  submodules: true
  	  	  fetch-depatch: 0

jobs 内に deploy-hugo という名前のjobを定義しました．　runs-on でjobを実行する仮想マシン（ランナー）の種類を選びます．ubuntu以外にもwindows serverやmacosが選べるみたいです．

steps に実行するコマンドを順に記述していきます．

最初に uses: actions/checkout@v3 でランナーにリポジトリのコードをチェックアウトします．ランナー上でリポジトリのコードを使用する際にはこれを必ず実行する必要があります．今回はランナー上でHugoのビルドを行うために必要です．

今回のレポジトリはHugoのThemeをサブモジュールとして含んでいるので submodules: true でサブモジュールもチェックアウトするようにします．

また， fetch-depth: 0 を設定することで全てのブランチとタグの全ての履歴をチェックアウトします．.GitInfoや.Lastmodに必要らしいですが，ここではそれらの説明は省きます．

1. Hugoのビルド

- name: setup hugo
  uses: peaceiris/actions-hugo@v2
  with:
    hugo-version: latest

- name: build
  run: hugo --minify

まず，ランナー上にhugoをインストールします. その後, hugoのビルドを実行します．

name: setup hugo のステップで uses: peaceiris/actions-hugo@v2 でhugoのセットアップを行います．

次に，ビルドを実行します． name: build のステップで，run: hugo --minify でビルドを実行します． --minify オプションで出力されるファイルを圧縮します．

2. ビルドしたポートフォリオサイトのデプロイ

今回はGitHub Pagesにデプロイします．便利な既存のActionsを利用します．

- name: deploy
  uses: peaceiris/actions-gh-pages@v3
  with:
    github_token: $
    publish_dir: ./public

パラメータとして渡している github_token の secrets.GITHUB_TOKEN は何かトークンを別で取得して与えなければいけないというものではなく，ランナーによって自動的に生成されるトークンなので設定する必要は無いです．

publish_dir はそのまま公開するディレクトリです．今回は他に特にパラメータを設定していないので，同一レポジトリの gh-pages ブランチにランナー上の ./public に出力されたビルド結果がコミットされます．

ここまでの hugo-deploy.yml の全体を掲載します．

name: hugo-deploy

on:
  push:
    branches:
      - master

jobs:
  deploy-hugo:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
        with:
          submodules: true
          fetch-depth: 0

      - name: setup hugo
        uses: peaceiris/actions-hugo@v2
        with:
          hugo-version: latest

      - name: build
        run: hugo --minify

      - name: deploy
        uses: peaceiris/actions-gh-pages@v3
        with:
          github_token: $
          publish_dir: ./public

レポジトリ側の設定

レポジトリ側で gh-pages ブランチを公開するように設定する．GithubのレポジトリのSettings→Pagesの”Build and deployment”の”Source”で”Deploy from a branch”を選択し，”Branch”で gh-pages を選択して”Save”を押下．

サイトの微修正

今回自分はドメイン直下のURLではない位置(example.com/hoge/ みたいな位置)にデプロイしたため，そのままではページが正常に表示されませんでした．

そこで，Hugoのコンフィグファイルの以下の２点を修正しました．

baseURL: https://example.com/hoge # 修正前： https://example.com
canonifyURL: true # 追加

canonifyURL を設定することで絶対パスを有効化します．

実際にデプロイしたものがこちらになります．https://23akei.github.io/myportfolio/

そのリポジトリはこちら：https://github.com/23akei/myportfolio

以上です． Thank you for reading!

参考

https://gohugo.io/hosting-and-deployment/hosting-on-github/

https://gohugo.io/getting-started/configuration/

https://docs.github.com/ja/pages/getting-started-with-github-pages/creating-a-github-pages-site

https://docs.github.com/ja/actions/learn-github-actions/contexts#github-context

https://docs.github.com/ja/actions/using-workflows/workflow-syntax-for-github-actions

https://docs.github.com/ja/actions/learn-github-actions/understanding-github-actions

https://github.com/marketplace/actions/github-pages-action

https://github.com/marketplace/actions/hugo-setup

https://zenn.dev/nikaera/articles/hugo-github-actions-for-github-pages

Hugoでポートフォリオサイトを作成する際の備忘録

2022-12-28T06:20:37Z

Introduction

この記事は筆者が１年放置したポートフォリオサイトの更新に際して，でHugoでポートフォリオサイトを作る際の手順をまとめておこうと思い，執筆するものです．

What’s/Why Hugo?

What’s?

Hugo is a static HTML and CSS website generator written in Go. It is optimized for speed, ease of use, and configurability. Hugo takes a directory with content and templates and renders them into a full HTML website.

（hugo README.mdより）

HugoはGolang（プログラミング言語Go）によって記述された静的ウェブサイトジェネレーターです．HTML+CSSで構成された静的サイトを生成するのに便利です．

Why?

筆者は今までに何度かHugoでブログや静的サイトを構築したことがあります．他の静的サイトジェネレーターの利用経験が無いため比較はできないのですが，Hugoには以下の良い点があると思います．

Markdownで記事が書けるという点がとても楽で良い．必要に応じてHTMLをMarkdown内に埋め込むことができる．
https://themes.gohugo.io/等で公開されているthemeを利用することで，いい感じのデザインのページを簡単に生成できる．

Hugoのインストール

LinuxやMacOSの環境の方はパッケージマネージャーを利用してインストールするのが楽でいいと思います．例えばUbuntu等apt環境だとこんな感じ．

$ sudo apt install hugo

Windows用ソフトウェアでよくあるインストーラパッケージは用意されておらず，Chocolatey等のパッケージマネージャーを利用する必要があったり，Dockerのイメージを利用する必要があります．個人的には面倒な気がするのでWSL上のLinuxにインストールして利用するのがいいと思います．

オープンソースなのでgoの開発環境が有る方は自前でビルドするのもいいかもしれません．

注意すべき点として，Hugoにはstandardとextendedの２つのエディションがあることが挙げられます．一部のThemeはextendedの機能を要求するため，基本的にはextendedをインストールするのがよいでしょう．以下に示す参考ページに具体的なインストール方法が示されていますが，パッケージマネージャーによってextendedのパッケージ名が異なるため注意してください．

参考：https://gohugo.io/installation/

はじめの１コマンド

hugo new site コマンドで新しいプロジェクトが生えます．

$ hugo new site myportfolio

例えば上記コマンドでカレントディレクトリの myportfolio 以下にhugoのプロジェクトが生えます．こんな感じに．

$ cd myportfolio/
$ ls
archetypes  assets  config.toml  content  data  layouts  public  static  themes

デフォルトのconfig.tomlはこんな感じです．こんな感じなんだ～（小並感）．

baseURL = 'http://example.org/'
languageCode = 'en-us'
title = 'My New Hugo Site'

参考：https://gohugo.io/commands/hugo_new_site/

gitでプロジェクトのソースを管理してる人は git init しておくと良いと思います．

テーマを適用する

今回私はHugo Profile を使います．画像少なめのポートフォリオサイト用Themeということで選びました．適当に選んだのでこの後変えるかも．（ちなみに前回Hugoでポートフォリオサイト作った時もこんな気持ちで，その一年後が今です．本当はThemeの入れ替えだけならわざわざプロジェクトを作り直す必要は無いのですが，記事のためにやりなおしています．）

テーマの使い方は各テーマのReadmeとかに書いてあるのでそれぞれ参照してください．以下，この記事はHugo Profileを使った説明になります．

とりあえず，submoduleとして themes 内にテーマを持ってきます．

myportfolio:$ git submodule add git@github.com:gurusabarish/hugo-profile.git themes/hugo-profile

テーマを編集する

Hugoのポートフォリオテーマははポートフォリオ機能だけなら，configファイルだけで完結してしまうことが多く（筆者個人の感想．n_themes=2），今回のThemeもそうでした．ですので，Hugoを紹介しているサイトとかでよくある hugo new コマンドを用いた新規記事の作成の説明は省きます．

ここでHugo ProfileのReadmeを読むと hugo new site の際に -f=yaml オプションをつけろと書いてありますね．デフォルトではconfigファイルはTOMLですが， yamlも指定できるらしい．Hugoのプロジェクトを立ち上げるときには，まず最初に利用するテーマを決めて，そのReadmeのUsageを確認することをおすすめします．

今回私はすでにオプションを指定せずにhugo new site を実行して config.tomlを作ってしまいましたが， config.toml を削除して config.yaml をテーマの exampleSite 内から持ってきたら解決しました．

yamlファイルを適当に編集して「とりあえず出せそうな感じになったな」と思ったら内容が激薄になっていました．

ローカルでのテストは hugo server コマンドでできます． localhost:1313 でテストサーバーにアクセスできます．実行中にファイルを更新すると自動でリビルドが走って更新されるので便利です．

デプロイしたサイトはこちらです．https://23akei.github.io/myportfolio/

以上です．実際のデプロイやCI/CDについては別記事で． Thank you for reading!

しがない大学生がレガシーコードに向き合った感想

2022-12-23T15:00:00Z

これはklis Advent Calendar 2022 24日目の記事です。こんにちは、klis19（3編）のnotch_manです。今日はクリスマスイブですね。皆さんはいかがお過ごしでしょうか。巷では熱々ムードが漂っていますが、私に関しては表題にあるように”レガシーコード”と相まみえています。そんな私がこの1年間で向き合ってきたレガシーコードに向き合った感想を綴ろうと思います。

結論

レガシーコードは向き合い続ければ必ず克服できる
ソースコードはメンヘラなので手を加え続けよう（手から離れたソースコードはその瞬間にレガシーコードになる）
レガシーと戦いやすい実装を心がける

はじめに

私は現在で大学での短期雇用、2社の長期インターン、また業務委託でソフトウェア開発を行なっています。ほとんどの現場のコードベースは長い年月を経て作られたものです。私のインターンでの主な業務は、いにしえのソースコードを解読し現世人が解読出来るものに復元することです。今日はそのうち1社と大学での業務でレガシーコード改善を行なった感想を綴ろうと思います。

10年以上の歴史のあるシステムの根幹にメスを入れる

PRTIMESでは現在PHPを始め、各種コードベースのリファクタリングやバージョンアップを進めています。最初は細かいライブラリのリファクタリングを行なっていき、現在は大規模な修正範囲を伴う作業を進めています。一般に、影響範囲の広いものほど放置される傾向にあります。しかし、その間にもサービスは成長を続けるので負債もさらに増加していく一方です。だから、誰かがいつかは手を付けなければいけません。私はこの1年で、そんなレガシーコードに向き合う精神と技術力を養うことが出来ました。

レガシーコードの改善は至ってシンプル

レガシーコード改善と名前は格好いいですが、技術的にやることは以下の2つだけでシンプルです。

ライブラリのリプレイス・バージョンアップを行なう
以前と同じ挙動を担保する

ただし、実際に手を加えると以下の様なことを考えなければなりません。そして、これには途方もない労力が必要になります。

メジャーアップデートで以前の互換が切られている可能性
将来のバージョンアップを見据えたライブラリ選定
本当に以前と同等の挙動をしているか確認する（これが一番難しい）

そして、技術以外に必要な物もシンプルです。最早、精神論ですが…（笑）

くじけない心
粘り強く調査→修正のサイクルを繰り返す忍耐力

はい、最後は精神論です。

「レガシーコードの改善は技術力だけでなく，それよりもむしろ精神力が要求されます．チーム内でレガシーコード問題の深刻さを共有し，精力的に取り組みましょう」

技術で解決出来る事は技術で殴れば解決できます。しかし、レガシーコードリファクタリング緻密に調査を積み重ねる、泥臭く1つ1つを修正していくなど技術以外の能力が要求されます。だから鍛錬を積み重ねて、これらの作業を行なう精神力を養っていく必要があると考えています。

これらを兼ね備えてやるべきことをやっていけば必ずレガシーを克服することが出来ます。今年、様々な現場でレガシーを解消してきた私が言うので多分間違いないと思います（笑）

結論1：レガシーコードは向き合い続ければ必ず克服できる

結論、何が起きても勇敢に向き合う腕力、忍耐力、技術力があればいつかは必ず克服できます。そして、究極のテストである「以前と同じ動作を保証する」テストを終えるだけで実績がそのまま評価に繋げられます。皆さんも臆すること無くレガシーコードに向き合い続けましょう。その力はソフトウェア開発以外でも必ず活かせます。

たった数ヶ月で腐敗したコードベースを手直しする

続いての事例は融合知能デザイン研究室で開発中のシステム「NextCrowd4u」です（以下N4U）。N4Uは融合知能デザイン研究室でサービスを運営しているCrowd4u（以下C4U）の後継システムとして現在開発中のシステムです。こちらは前任者から引き継ぎ現在も開発を続けています。

事件は唐突に起きる

私は4月から開発業務に関わり始めましたが、早速トラブルが発生しました。

と言うわけで、復旧作業をしようと思ったのですがまず本番環境への接続方法を確認するのに手間取りました。

結局、過去のチャットログから接続方法を確認しログイン出来ました。これ以外にもトラブルが多発している状態で、当時の現場はとても混乱してました。コードベースも前任者からの引き継ぎが十分でなく、ゼロからコードリーディングをして何とかデバッグするという状況でした。

結論2:ソースコードはメンヘラなので手を加え続けよう

ソースコード、特にPythonのようなドラスティックな変化をする言語は手を加え続ける必要があります。数ヶ月コードベースに手を付けられなかったら、pip install -r requirements.txtすら通らなくなるでしょう。まるでメンヘラですね、手がかかって本当に困ります。

エンジニアはメンヘラと付き合いがちという俗説をよく耳にします。確かに、プログラムがメンヘラみたいなものなのでそれに扱い慣れてたり類似性を感じるからでしょうかね。個人的にはPythonとかすぐに壊れがちの言語をメインに扱っている人ほどメンヘラと付き合ってるのでは？と思ってしまいます。言語別で統計を取ったら面白そうですね（笑）

このように、開発陣でコントロール出来ないシステムを運用するのはリスクであり、早急に開発体制を立て直す必要がありました。

STEP1

まず、システムをコントロール下に置くために私がシステムやコードベースの全容の把握を行なう必要があります。しかし、稼働中のシステムの運用を止める訳にもいかないので、時間稼ぎのためオペレーション部分から立て直しを進めていきました。最初は私1人で作業を行ない、その手順を全て示すことで他の人も同じ作業が出来るように障害対応と全体のレベルアップ施策を当時に行なっていました。

深夜の復旧作業は中々辛かったですが、復旧後は1つ1つの手順を説明し着実にレベルアップを図っていきました。

STEP2

6月頃から本格的にコードベースの復旧に取りかかります。しかし、この時には4～5月のシステム障害対応の段階でシステム開発の手が止まってしまい担当者もいなくなったことで完全にレガシーシステムと化してしまいました。この時の問題点は概ね以下の通りです。

Python3.7で動いている
ライブラリのメジャーアップデートなどで互換の維持が出来ない
アーキテクチャの問題で耐障害性が低くシステムダウンが頻発

4月時点では右も左も分からない状態だった開発陣もシステム障害に向き合う中でコードベースへの理解が深まっていました。そこで私はマネジメントやコードレビューに徹し、さらにメンバーのスキルの底上げを図っていきました。レガシー改善では以下のワークフローで開発を進めました。これにより、手を動かしながら私のノウハウも伝えることができメンバーの開発力を大幅に向上させることに成功しました。

設計に関してはDesignDocを作成
DesignDocでソフトウェア設計に関してnotch_manの経験も踏まえつつアドバイス・改善
GitHubでタスクチケット（Issue）を作り開発着手
一旦、自力で実装する
コードレビューで設計面でnotch_manのノウハウを伝授

これらの手順に沿ってまずライブラリのアップデートや明らかなデッドコードの削除を進めていきました。そして、それが終わった後にソフトウェアアーキテクチャに問題になっていた箇所の大規模リファクタリングを実施しました。（これについては開発者ブログの記事をご覧下さい）。最後は以下のPRによって一旦のレガシー改善は完了としました。4月にはてんやわんやしていたチームが見事大規模なレガシー改善を達成した瞬間です。

STEP3

これまではレガシーの改善に尽力しましたが、今後はサービスグロースを進めながらレガシーと戦う必要があります。 n4uのレガシー改善としては主に以下の項目が残っています。

テストコードの実装
CRUDロジックを新設計の実装にフルリプレイス
各種ライブラリの見直し
テストを含めたCI/CDの構築
ログ基盤の改善

今後、n4uの開発チームは新機能開発を積極的に行なっていき、これまで以上のリリース速度で研究室が目指すサービスの実現に向けて歩みを進めていきます。その一方で、過去の負債やこれから生まれる負債についても戦略的に向き合う体制を構築していきます。

結論3: レガシーと戦いやすい実装を心がける

これは今後のレガシーコードの向き合い方の話です。と言いつついきなり残念な話ですがですが、システムというのは誕生した瞬間に腐り始めるものです。つまり、作ったシステムはその瞬間にレガシーとなるのです。そのため、レガシーを生まないことはほぼ不可能です。だから、システムを開発するときにはコードベースが腐ることを前提として実装を行なう必要があります。少し前に技術負債の話が話題になりましたが、私のこれまでの経験を踏まえると以下の点を気をつける必要があると思います。

SOLID原則を守る
手に負えなくなった機能は置き換えやすいように実装を行なう
テストコードを実装する（ユニットテストだけでなくE2Eテストも用意する）
CI/CDを整えてテストやコード規約を強制的に機能させる仕組みを用意する。

まず、1つ目について触れます。ソフトウェアの開発原則には様々な物がありますが、Web開発ではSOLID原則を意識するだけでかなり改善すると考えています。特に単一責任の原則と依存性逆転の原則は非常に大事だと思っているので、この辺りの実装についてはコードレビューで品質を保つように努めていきます。

2つ目ですが、時の担当者がメンテナンスをしなければならない機能に手を付けられないとそれが放置されてしまい負債という形でレガシーが引き継がれてしまいます。だから、困ったときには捨てることが出来るシステム設計を心がける必要があります。関心の分離はソフトウェアの設計で大事ですが、特にメーラーなどの外部ライブラリを使う際の変更容易性には注意して開発を行ないます。

3つ目と4つ目は当たり前の話ですね？ただ、テストコードや静的解析をツールを頑張って導入しても使われなかったら意味が無いです。そのためCI/CDの中でそれらを強制的に動かす仕組みを整えていきます。こうすることで、テストや静的解析の効果を最大限発揮し将来に渡って一定のコード品質を保つことが出来ます。

このようにレガシーを生み出さない、あるいは改善するためには普段からどうすれば戦いやすいか？という視点に立つ必要があるなと痛感しました。今後、N4Uの開発の中でこうした知見が貯まっていったら積極的に紹介していきます。

雑にこの1年を振り返る

この1年で超ド級の謎物体やら小学生もビックリするような限界状態の中で前に進み続ける腕力、精神力や技術力を身に着けることが出来ました。来年は攻めの姿勢で構えながら、さらなる深淵へと歩みを進めていきたいと思います。

そして、今年はめっちゃ頑張った。その結果、レガシーコードリファクタリング業（みならい）は名乗れる程度に成長したのでは？と思ってます。研究室に眠るレガシーシステムの改善のご用命は融合知能デザイン研究室へ（笑）

最後に

キラキラ光る街並み、その裏側には多くのエンジニアの汗と涙が詰まっています。2人の愛の育みも大事ですが、そういった人達の光を浴びぬ物語を時々で良いから思い出してあげてください。皆様、素敵なクリスマスをお過ごしください。

（私のクリスマス？おっと、何処かで案件の燃えてる香ばしい匂いがするぞ…）

簡単に始める自動デプロイ生活

2022-12-20T13:00:00Z

こんにちは、notch_manです。とある講義のメンターをやっていて色々思うところがあったので、今日は簡単に自動デプロイを実現する方法を紹介したいと思います。

デプロイって難しそう

デプロイって皆さんに聞くと大体こんなワードが返ってきます（私の観測範囲）。

GitHub Actionsでいろいろ書くんでしょ？難しそう

CircleCIで自動デプロイはやったことありますが、個人だとお金がかかるし…

友人にプロが居るのでいつも丸投げです

確かに、複雑なデプロイや環境毎に変数値が変わるなどの事情があればこれらのサービスを使った方がいろいろな事が出来ます。ただ、デプロイってそんな難しいものなのでしょうか？ここでデプロイという単語を辞書で見てみましょう。

デプロイとは、配備する、配置する、展開する、配置につく、などの意味を持つ英単語。ITの分野では開発したソフトウェアを実際の運用環境に配置・展開して実用に供することを指す場合が多い。（出典：https://e-words.jp/w/デプロイ.html）

これらをまとめると、みなさんが難しいと思う自動デプロイはたった3つの条件を満たせばどんな方法で実現しても良いことが分かります。

何かを実行したらソースコード・成果物が所定の位置に配置される
所定の位置に配置されたソースコード・成果物が実用的な動作をする
それらがなるべく人の手を介さずに処理される

というわけで、これらを満たすとても簡単なデプロイスクリプトを実装してみます。

rsyncで始める自動デプロイ

初心者がデプロイ組むときにサーバーのURLとかいろいろ考えるの難しいですよね？でも、そんな状態でも大体”公開鍵認証”でSSHは通じているはずです。となれば、この経路を使ってファイルを置くことが出来そうですね。というわけで、SSH経由で自動デプロイをしてみましょう。これを実現する方法にrsyncというものがあります。rsyncは差分ファイル転送を行なうツールになっています。差分ファイル転送を雑に説明すると、あるファイルに更新があった場合に別のサーバーなどの対応するファイルと変更を同期する機能のことです。rsyncについてはこちらのサイトがとても参考になります。

では、rsyncを使ってデプロイスクリプト（deploy.sh）を書いてみましょう。

rsync -r -a <転送したいファイルを含んだフォルダ>/* <remote server>:<配置したいディレクトリ>

さらに~/ssh/configを編集して鍵情報などを登録しておきます。

Host <remote server>
  HostName <ip address or server name>
  User example
  IdentityFile ~/.ssh/example_key
  ServerAliveInterval 60

以上でデプロイスクリプトの完成です。あとはbash [deploy.sh](http://deploy.sh) を実行すればデプロイが走ります。

まとめ

自動デプロイとか一見すると難しいワードですが、以下を満たせば手段は何でも良いです。

何かを実行したらソースコード・成果物が所定の位置に配置される
所定の位置に配置されたソースコード・成果物が実用的な動作をする
それらがなるべく人の手を介さずに処理される

特に講義で頻繁にデプロイをする方々はぜひ参考にしてみてください。最後になりますが、技術で解決出来る事はさっさと技術で解決して本質にしっかり向き合っていきましょう！

NextCrowd4u概説

2022-12-08T01:26:23Z

融合知能デザイン研究室のあけいです．我々が現在開発しているWebサービスであるNextCrowd4uについて，その概略を説明します．

Crowd4u概説

まず，"Next"以前の「Crowd4u」について簡単に説明します．一言で言ってしまえば，Crowd4uはクラウドソーシングプラットフォームです．
Corwd4u

クラウドソーシングとは

「クラウドソーシング」をご存知でない方も結構いると思われるので，まずクラウドソーシングについて簡単に説明します．クラウドソーシングの「クラウド」は"Crowd"すなわち"群衆"を意味します．（"Cloud"すなわち"雲"，ではないです！）それと，外注すなわち"アウトソーシング"を組み合わせた言葉，それがクラウドソーシングです．つまりクラウドソーシングは，不特定多数の労働者に対するアウトソーシングです．クラウドソーシングを利用した具体的なサービスを以下に示します．

etc...

Crowd4uもここに挙げたようなクラウドソーシングプラットフォームの１つです．
クラウドソーシングは不特定多数の労働者に仕事を依頼できるため，

大量のタスクの早期完了
不特定多数の人間の知見の収集（＝集合知の形成）

などが可能になります．

大学の研究室による運営

Crowd4uは融合知能デザイン研究室が運営するクラウドソーシングプラットフォームで，主にクラウドソーシングの学術研究のために利用されています．他の大学の研究にも利用されており，それらの研究の要求に応じて機能を実装するなど，学術研究との結びつきの強いプラットフォームです．

ちなみに，Crowd4uに決済機能は無いため，あくまでもボランティアでタスクを請け負ってもらうという仕組みになっています．

N4U概説1 - Human+AI

「NextCrowd4u」次期Crowd4uシステムについて説明します．"Next"Crowd4uには今までのCrowd4u，ひいては既存のクラウドソーシングプラットフォームと大きく異なる点があります．それはすなわち"AI"です．近年急速に発展する機械学習，それらAIの能力は一部領域では人間を凌駕するまでに発展しました．今後AIがより多くの場面で利用されると予想されます．

NextCrowd4uではAIと我々がより密接に関わるであろう将来に向けて，AIと人間のよりよい関わり方を研究するために，AIに対するクラウドソーシングを行う機能を実装します．

AIに対するクラウドソーシング

クラウドソーシングというのは"人間"にタスクをこなしてもらうというのが一般的ですが，現在では人間にその対象は人間に留まりません．
AIの性能を競うコンペティションサイトとしてKaggle等があります．これらのコンペサイトでは，コンペのお題に対して不特定多数のAI開発者が各々のAIの性能を競い，コンペの主催者はAIやAIによって得られたお題の結果を得ます．これは不特定多数のAI（とその開発者）に対するクラウドソーシングといえます．従来のクラウドソーシングのタスク依頼対象である人間ワーカに対して，AIによるクラウドソーシングにおいて「AI（とその開発者）」を一体とみなしてAIワーカと考えます．

人間とAIのクラウドソーシングの違い

AIに対するクラウドソーシングは人間に対するそれとは異なる点があります．人間ワーカに対するクラウドソーシングでは，（悪意のあるものを除けば）基本的に高品質なタスク結果を期待できます．しかし，人間ワーカはタスクの実行に時間がかかります．一方，AIワーカは大量のタスクを素早く実行できます．しかし，特に教師データを必要とするAIにおいては，教師データが無い，もしくは少ない状態では十分な品質のタスク結果を得ることができません．そもそも，機械学習モデルの学習に用いられる教師データは主に人間のワーカによるラベル付けで作成されています．そのため，AIの学習を行う前にはたいてい人間ワーカによる仕事があります．

Human+AI Crowd

NextCrowd4uでは前述の背景を踏まえ，AIに対してもクラウドソーシングが可能なプラットフォームとします．つまり，NextCrowd4uは"不特定多数の人間"と"不特定多数のAI"：Human+AI Crowdに対するクラウドソーシングを行うプラットフォームです．人間へのタスク依頼とAIワーカへのタスク依頼を柔軟に組み合わせることで，より迅速により高品質なタスク結果が期待できます．

N4U概論 2 - メタプラットフォーム

上でいくつかのクラウドソーシングプラットフォームを挙げましたが，それらのプラットフォームにはそれぞれ特徴があり，状況やタスクの目的に応じてそれらを使い分けることが出来れば，より効率的により良い結果を得ることが期待できます．そこで，NextCrowd4uはクラウドソーシングタスクを直接扱うのではなく，複数の既存プラットフォームを扱う「メタプラットフォーム」を目指しています．例えば

APIなどを用いて既存のクラウドソーシングサービス上でタスクを発行．
タスクの結果を得たら，それをNextCrowd4u上で統合，分析する
結果に応じて動的に各プラットフォームでタスクを発行する

...という流れを繰り返すことを想定しています．
このように１つの目的に対して状況に応じて柔軟に複数のサービスを用いることが可能なプラットフォームを目指しています．

まとめ

NextCrowd4uは
Human+AI Crowdに対するクラウドソーシングを実現するメタプラットフォーム
です．

今後我々N4U開発チームは最新の研究の成果などを取り入れながらNextCrowd4uの開発を行い，AIと人間がより高度に融合した社会の基盤づくりを進めていきます．

RDS上のDBのデータをローカルで同期できる環境を作った話

2022-12-01T05:54:39Z

初めまして、融合知能デザイン研究室に仮配属中のギルドです。(留年しなければ「仮」がとれるはず。。。)
融合知能デザイン研究室で開発しているNextCrowd4uの開発チームに最近加わったため、加入後に初めて行ったことについて書いていきたいと思います。

NextCrowd4u(N4U)について

まだブログも創設から間もないという事で、NextCrowd4Uについてザックリ説明していこうと思います。 NextCrowd4u(以下N4U)は、「世界をより良い場所にするためのマイクロタスクを実行するための非営利プラットフォーム」として2008年ごろから稼働しているCrowd4uの後継システムです。 N4U開発チームで具体的にどんなことを行ってきたかについては、こちらの記事をご覧ください。

N4Uの開発現場で発生していたﾁｮｯﾄ面倒な事

さて、実際の開発ではサーバー上のコードを直接編集。。。するわけでは当然なく、基本はローカルの環境で開発して、GitHubでコミットやらレビューやらしてからデプロイするわけですが、そうなると開発やテストが行いやすいため、実際のサービスのデータをローカルでも扱いたいというニーズが出てきます。 N4UはAWSをサーバーのインフラとして使用しており、DBもAmazon RDS for MySQLを使っています。これまでは、RDS上にある本番環境のデータをローカル環境で使用するために、踏み台サーバーを2回通してSCPコマンドを使ってデータを取得する必要がありました。このような環境はテストや開発において支障がでていたとのことで、もう少し手軽に本番とローカルのデータを同期したいというニーズが生まれました。

やったこと

やったことは非常にシンプルで、N4Uを稼働しているサーバーから、1日1回DBをダンプして踏み台サーバーに送るような環境を作成します。(下図) そして、ローカルでリストア用のスクリプトを実行することで、踏み台サーバーにアクセスし、ダンプされたDBをダウンロードして、ローカルのデータベースにリストアするようにしました。\

これを実現するためにやったこととしては

N4Uサーバー
1. RDSのDBをダンプし、踏み台に送信するシェルスクリプトを作成する(dump.sh)
2. 上記のスクリプトを定期的に実行する(cron)
踏み台サーバー
1. AWSでEC2の環境を新しく作成する
2. nginxを導入し、ベーシック認証ができるようにする
ローカル環境
以下のようなシェルスクリプトを作成する。(restore.sh)
1. 踏み台サーバーからDBをダウンロードする
2. ローカルのDBにリストアする

踏み台サーバーの設定に関しては、私が書くよりも分かりやすい記事がたくさんあるかと思います。
そのため、ここからはDBのダンプスクリプトとリストアスクリプトについて書いていきます。

N4Uサーバー：DBを定期的にダンプする

1. DBをダンプするdump.shを作成する
というわけで、以下のようなダンプスクリプトを作成しました。データベースの容量がある程度大きいことが想定されますのでgzipを使用して圧縮をしています。

#!/bin/bash

# RDSからDBをダンプする(dump.sqlを作成)
mysqldump -h {RDSのホスト名} -P {ポート番号} -u {ユーザー名} -p{パスワード} -p {DB名} > dump.sql

# gzipに圧縮
gzip dump.sql

# scpコマンドで踏み台に送信する
scp -i {秘密鍵のパス} dump.sql.gz {踏み台のホスト名}:{踏み台のダウンロード先のパス}

パス等が多いという事もあり、文字だらけですが以上のようなスクリプトを作成しました。
注意する点としては、パスワードは-pの後に空白を入れずに入力するという事です。空白を入れてしまうとDB名として認識されてしまいます。
また、私の環境での話ですが、パスワードをDB名より先に入力しないと-p {DB名}の部分がパスワードとして認識されてしまい、ダンプできないという現象が発生しました。
そのため、パスワードを先に記述してエラーを回避しています。

2. dump.shを定期的に実行する
次にこのスクリプトを定期的に実行していきます。
AWSということで、Amazon EventBridge！と行きたいところですが、AWSを使用した開発経験が過去に皆無だったこともあり、無難にcronで定期実行することにしました。
コマンドラインで以下をたたき、crontabを開きます。

crontab -e

次にcronのスクリプトを書いていきます。
以下は毎日01時00分にシェルスクリプトを実行するスクリプトです。パスは適宜書き換えてください(ex. ~/tools/dump.sh)

0 01 * * * sh dump.sh

ちなみにcronの時間指定は{分} {時} {日} {月} {曜日}で、指定しない項目には*を指定します。
以上の設定でN4Uサーバー上で毎日DBをダンプする環境が出来上がりました！

ローカル環境：DBを踏み台からダウンロードしてリストアする

N4UサーバーからDBをダンプして踏み台に送信できるようになったので、ローカル環境でリストアするスクリプトを書いていきます。ちなみにダウンロードにはwgetコマンドを使用して行っていきます。また、先述した通り踏み台サーバーはベーシック認証を設定しているため、wgetのオプションで指定し、ローカル環境としてDockerを使用しているためDockerコンテナのMySQLにリストアしていきます。

#!/bin/bash

# DBをwgetでベーシック認証を挟んでダウンロードする
wget -P {ダウンロード先のパス} --http-user={ユーザー名} --http-passwd={パスワード} http://{踏み台のIPアドレス}:{ポート番号}/dump.sql.gz
# gzip化されているので解凍する
gunzip -f dump.sql.gz
# Dockerコンテナ内のSQLにリストアする
cat dump.sql | docker-compose -T {コンテナ名} mysql -u {ユーザー名} -p{パスワード} -p {DB名}

以上でrestore.shも完成しました！
以上のスクリプトをローカル環境で実行することで(bash restore.sh)、ローカル環境に本番環境のデータが同期されるようになりました！

おわりに

以上が私がN4Uの開発チームに入ってからの初めての仕事になります。今後、更に開発に携わっていくことになるかと思いますので、このブログへのアウトプットも含めて頑張っていきたいです。ここまで拙文にお付き合いいただきありがとうございました！

融合知能デザイン研究室でエンジニアブログを始めました

2022-11-27T15:25:32Z

初めまして。融合知能デザイン研究に所属する現在B4のnotch_manです。融合知能デザイン研究室（fusioncomp lab）は2017年に立ち上げたAI+人間+ビッグデータによる融合知能の研究を進める研究室です。

融合知能デザイン研究室のHPはこちら

今回は融知研のエンジニアブログの記念すべき初投稿として、エンジニアリング視点で融知研の目指す方向、エンジニアブログを開設した理由などについて書いていこうと思います。

エンジニアブログを開設した理由

私たちがエンジニアブログを開設した理由は、自分達の持つ知見を外部に発信することでエンジニア界隈全体に少しでも貢献したいと考えたからです。

エンジニアブログは様々なIT企業が技術的知見を外部に発信する場として積極的に運用されています（所感）。例えば、PRTIMES様もエンジニアブログを公開しており、業務内外で得た知見を外部に共有する文化が広まりつつあります。

PRTIMES 開発者ブログへ

また、私たちにもいろいろなメリットがあります。

ブログを書くメリット

ブログを書くメリットは以下の様なものがあると考えています。

自分がやってきたことの記録になる
記事を書くことで身に着けた知識が定着する
ポートフォリオとして活用出来る
研究室での開発という特異な環境の知見自体に価値がある

1つ1つ説明していきます。

自分がやってきたことの記録になる

研究では手探りでいろいろなことを進めていきます。すると、過去に自分がやったことを忘れて同じようなことを検索したり、車輪の再発明をしたりと無駄な時間が増えてしまいます。これまでの自分のログを文章としてまとめることでそれらを振り返ることが出来るようになります。

記事を書くことで身に着けた知識が定着する

例えば、開発中に何かのバグに遭遇したときに大抵の場合は手探りで解決してしまうと思います。しかし、バグが何故生まれたのか？それを防ぐことは出来ないのか？あるいは技術的な限界があるのか？それらについて深い洞察を行なうことはあまり無いと思います。これらをブログ記事を書くことをきっかけに確かな知識として定着することが出来るようになります。何故なら、第3者に自分が直面した課題、その解決策を伝える時に原因から解決策まで完結に、明確に伝える必要があるからです。何となく弄ったらバグが治りました！なんて記事は何の知識にもならないですし、他の人に伝わる内容にはなりません。他に人に伝えるには何となくで済ましたことを1つ1つを言語化し、それを理解する必要があります。それらの活動を通じて、本物の知識を身につけることが出来ますし、ついでに文章執筆スキルも向上させられます。

ポートフォリオとして活用出来る

最近のIT関連の就活ではこれまでの実績を要求されがちです。ここで、顕著な実績（学会やコンテストでの受賞歴など）があれば問題無いですが、私たちのような研究室での開発は公に出来ない事も多いので不利になりがちです。しかし、何はどうであれ開発していることに変わりはなく、適切なプロセスを踏んでいればIT業界で働くための基礎体力は身に付いてます。エンジニアブログで執筆する内容はそのような基礎体力を証明する明確なアウトプットだと考えています。さらに、これらを地道に積み上げていき融知研のエンジニアブログが一定の知名度を獲得すれば、その記事を書いているという事実が実績にもなります。訳の分からないコンテスト・ハッカソンに参加したり奇抜なポートフォリオサイトを作るのも良いですが、ブログ記事を通じた地道なアウトプットも1つの戦略として有効です。

研究室での開発という特異な環境の知見自体に価値がある

私たちは研究室でシステム開発を行なうという稀な環境に属しています。この特異性として以下が考えられます。

人が2～3年スパンで総入れ替わりする
研究がメインであるためシステム開発は副業的感覚
専任のエンジニアが居らず、属人化が進む
たまたまプログラミング得意な人が居れば何とかなるが、居ない場合はとても苦労する
いずれの状況に関わらずサービスはユーザーに価値を提供し続ける

私が開発に関わり始めたのは2022年の5月頃ですが、前年度まで居られた優秀な方は全員卒業してしまいゼロからの再スタートになってしまいました。幸い、前任者ほどでは無いですが私にもある程度の知見がありギリギリのところでサービスを提供し続けられています。しかし、そちらを優先しているが故に研究室内のネットワークの管理に手が回らないなどの弊害も生じています。これらは徐々に解消しつつあります（これについては別途記事を作成します）が、このような特殊な環境での開発知見はそれ自体一定の需要があるのではないかと考えています。私たちはそのような知見を積極的に外部に公開することで、ソフトウェア開発全般に対して微力ながら貢献できれば良いなと考えています。

融合知能デザイン研究室のエンジニアリングの目指す方向

私たちが今後目指すのは次の3つです。

Crowd4uのサービス維持
NextCrowd4uのサービス提供を目指す
挑戦できる環境を整える

Crowd4uのサービス維持

Crowd4uは2008年頃から稼働している「世界をより良い場所にするためのマイクロタスクを実行するための非営利プラットフォーム」です。こちらでは延べ200万回以上のマイクロタスクが実行され、多くのプロジェクトが行なわれてきました。また、私たち融合知能デザイン研究室の研究の要に位置づけられるサービスであり今後もサービスの提供を持続していく必要があります。

Crowd4uはこちらからアクセスできます

ただ、現在Crowd4uのサービス維持に当たって以下の様な課題が山積しています。

各種バージョンが古くセキュリティ上の課題が深刻である
モノリスなEC2を抱えている
前任者からの引き継ぎが十分ではない

ただ、我々はこの1年でこれらに立ち向かうための基礎体力を身につけてきました。新機能開発とは異なり、このような課題は適切に進めていけばいつかは必ず終わる作業です。その事実は後述するNextCrowd4u開発で証明しました。多くの課題があり、時間もかかりますが1つ1つ確実に前に進んでいきます。

NextCrowd4uのサービス提供を目指す

NextCrowd4u（N4U）はCrowd4uの後継システムとして昨年から開発が本格化したプロジェクトになっています。ただ、昨年から開発と言っても4月で担当が総入れ替わりし、ほぼ0の状態からスタートしたプロジェクトです。 N4Uは3月下旬から研究目的でテストリリースが始まっていました。しかし、これまでとは全く違う言語・フレームワーク・アーキテクチャで開発していたが故にいくつものトラブルが発生しました。これらを解消するには多くの作業が必要で、半年近く経った11月末にそれらの機能改修が終了しシステムの安定性を大きく向上させることに成功しました。

私たちは知識も経験も無い中、手探りですが課題を洗い出しそれらをタスクチケットに起票して1つ1つ進めていきました。並行していた新機能開発も含めてですが、このプロジェクトだけで実に100以上のタスクチケットが立てられました。これらを進めるのは途方もない作業で、負担も大きかったと思います。しかし、私たちは途方もない量でも1つ1つ進めていけば前に進むことを実感しました。そして、やり続ければいつかはやり遂げられることを経験しました。

今後は新機能開発やセキュリティ面の改修を進めていき、来年のリリースに向けて攻めの姿勢で開発を続けていきます。

挑戦出来る環境を創る

私は挑戦するマインドがとても大事だと思っています。新しいサービスを作るにしても、レガシーなシステムを直すにしても多くの壁があります。時にこの壁はとても厚く、越えるのを躊躇ってしまうレベルの物かもしれません。しかし、誰かがこの壁を越えることに取り組まなければ私たちは前に進むことは出来ません。

これまでも、私を中心に以下のような新しいことに取り組んで来ました（これらについては追々ブログとして公開する予定です）。

レガシーシステムのバージョンアッププロジェクト
レイヤーアーキテクチャの採用によるAPIのリファクタリング
ローカルと本番環境のデータベースの同期

その他にも研究室の取り組みとして以下のようなことをやりました。

サーバー構築を組み立てから実施
オープンラボの運営を従来と大きく変え、多くの見学者を動員
エンジニアブログの立ち上げ

今年、行なった様々なことは主に私を中心に取り組んだ内容になります。 1つ1つの壁は厚かったですが、皆が力を合わせ助け合うことでそれらを越えることが出来ました。この成功は私たち全員の挑戦するマインドが高まり、積極的な行動があったからこそ成功したものです。

私は、このような挑戦するマインドを持った人達を増やせれば研究も開発もさらに大きく進んでいくのではないかと考えています。そして、私をはじめこの1年プロジェクトに関わった方々には多くの成功や失敗を経験し、たくさんのノウハウを貯めています。

今のラボにはそういった頼もしいメンバーがたくさん居るので、何かやりたい事があったら積極的に手を挙げてドンドン取り組んでいきましょう

既に多くのメンバーが自分のやりたい事を積極的に行動する雰囲気が出来つつあり、今後も多くのことに取り組んでいく予定です。もちろん、本業は研究なのでそれを疎かにしてはいけないです。しかし、せっかくの機会なので学生時代にしか出来ない活動をたくさんやっていきましょう。

私は、そのような雰囲気作りを今後も積極的に行なっていくつもりです。

最後に

このブログでは今後、研究や開発で詰まったことの知見共有、チーム開発のノウハウなどを積極的に発信していきます。引き続きよろしくお願い申し上げます。

融合知能デザイン研究室 エンジニアブログ

CeleryのBrokerとResultBackendをElastiCache(Redis)からSQS+DynamoDBに移行した話

はじめに

Celeryとは

AWSでのCELERY_BROKERの選択肢

SQSではRESULT_BACKENDを受け取ることができない…

どう実現するか

おわりに

出典

令和5年に爆誕したオレオレFWの話

免責事項

オレオレFWとは

オレオレFWを作る利点

オレオレFWを作った動機

ちょっとの修正で長生きするフレームワークを目指す理由

ORMを使いたくない

ライブラリやフレームワークの魔法に頼らない

今回作ったオレオレFWについて

1つの処理を一貫性のある作法に基づいて実装する設計

オレオレFWの紹介

Router層（Routers+Actions）の説明

Controller層の説明

Repository層の説明

Store層の説明

まとめへ

オレオレを現場に投入したい方へ

真実のまとめ

ここから先は真実をお伝えします

VPC PeeringとALBのバーチャルホストで環境の切り分けとコスト削減を両立させる

はじめに

今回作成する環境

理由：ELB,高い・・・

実装

VPC ピアリング

Fargate SPOTの作成

最後に

ﾜﾀｼ、ﾗﾑﾀﾞ、ﾜｶﾗﾅｲ

はじめに

前提条件

①おれのかんがえた最強の構成

Lambdaが外部サービスと通信できない

②実際に採用した構成

終わりに

AWSのコストを$200減らすために行ったこと

はじめに

1. 余計なリソースの削除

2. STAGING環境の改善

①FargateのSpotインスタンス化

②タイムスケーリングの導入

おわりに

M1とWSL両方で動作するJupyterLabのDockerファイルを作った話

はじめに

この記事で扱うもの

この記事で扱わないもの

ファイル構成

requirements.txt

Dockerfile

docker-compose.yml

起動

参考

Deta.shでサクッとウェブアプリをデプロイしてみる

注意

はじめに

Deta.shとは

早速アプリを作ってみる

Deta CLIのインストール

アプリケーションを作る

Detaにデプロイ

おわりに

おまけ

参考

GitHub ActionsではじめてのCI/CD

Introduction

GitHub Actionsで出来ること/やりたいこと

Workflowの定義

Workflow発火条件の定義

Jobの定義

1. Hugoのビルド

2. ビルドしたポートフォリオサイトのデプロイ

レポジトリ側の設定

融合知能デザイン研究室エンジニアブログ