TECH PLAY

ニフティ株匏䌚瀟

ニフティ株匏䌚瀟 の技術ブログ

å…š517ä»¶

はじめに 皆さんこんにちは 新卒䞀幎目の宮村です 珟圚の業務では、䞻にOpenID Connect(OIDC)を䜿甚した基幹システムを運甚しおいたす。 そのため今回は、業務を通じお孊んだOIDCの基瀎に぀いお発信しおいきたいず思いたす。 この蚘事の前提 今回のハンズオンはWindowsのPowerShellを前提にしおいたす。 おそらく、MacやLinuxでも動䜜するず考えおおりたすが、保蚌はできたせん。 以䞋の蚘事等を閲芧し、OIDCの抂芁がわかっおいる前提で説明したす。 https://qiita.com/TakahikoKawasaki/items/498ca08bbfcc341691fe   ハンズオン準備 今回䜿甚する゜ヌスコヌドのクロヌン たず、準備ずしお今回䜿甚するOIDCのサヌバヌ django-oidc-provider をGit cloneし、exampleディレクトリに移動したす。 $ git clone https://github.com/juanifioren/django-oidc-provider.git $ cd django-oidc-provider/example   このexampleディレクトリには、実際にdjango-oidc-providerを導入した際のOpenID Provider(OP)の実装䟋がありたす。 Dockerコンテナの䜜成 exampleが少し叀くそのたたでは動かなかった点ず今回のハンズオンの郜合䞊、DockerFileの内容を以䞋に倉曎しおください。 ※あくたでテストであるため、スヌパヌナヌザヌ情報をファむルに盎曞きしおいたす。 FROM python:3.10 WORKDIR /app COPY . /app RUN pip install --upgrade pip RUN pip install --no-cache-dir -r requirements.txt RUN python manage.py migrate RUN python manage.py creatersakey # 環境倉数でデフォルトのスヌパヌナヌザヌ情報を蚭定 ENV DJANGO_SUPERUSER_USERNAME=admin ENV DJANGO_SUPERUSER_EMAIL=admin@example.com ENV DJANGO_SUPERUSER_PASSWORD=admin # スヌパヌナヌザヌを䜜成既存の堎合はスキップ RUN python manage.py createsuperuser --noinput || echo "Superuser already exists" EXPOSE 8000 CMD ["python", "manage.py", "runserver", "0.0.0.0:8000"]   以䞋のコマンドで実際に起動しおみたしょう $ docker build -t django-oidc-provider . $ docker run -d -p 8000:8000 django-oidc-provider   http://localhost:8000 で以䞋の画像が確認出来たら成功です。 テストClientの远加 Create your clients をクリックしたしょう。 ここでいうclientはOPを䜿甚するクラむアントのこずを指し、Relying Party(RP)ずも呌ばれたす。 クリック埌、ログむン画面が衚瀺されるため、ID、パスワヌドどちらも admin を入力したしょう。 ログむン埌は 巊サむドバヌのClientsの隣 にある +Add をクリックしたす。 その埌、以䞋を入力したす。それ以倖はそのたたでOKです Name: テスト Response types code id_token id_token token Redirect URIs: http://example.com Scopes: openid profile email address phone 入力䟋 この埌、Saveをクリックし、生成したclientを確認するず以䞋のようにClient IDずClient Secretが自動生成されたこずが確認できたす以䞋はあくたで䟋です。 これらの情報は、リク゚ストを送信したclientが正芏のclientであるこずをOPが確認するために䜿甚したす。 この埌のハンズオンで䜿甚するため、これらの情報をメモしおおきたしょう。 テストナヌザの䜜成 巊サむドバヌのUsersの隣 にある +Add をクリックしたす。 するず、以䞋の画面に遷移するため、以䞋の情報を入力しSaveをクリックしたす Username: test_user01 password: test_user01 するず、以䞋の画面ぞ遷移するため First name: user01 Last name: test Email address: example@google.com ず入力しSaveをクリックしたす。 これで、䞋準備は完了したした。 ハンズオン 実際に蚭定したOPに察しおログむンしおみたしょう。 今回は、OIDCのシヌケンスの䞭で最も䞀般的なAuthorization Code Flowで詊しおみたす。 ログむンAuthorization Request 初めにブラりザの シヌクレットブラりザモヌド を立ち䞊げ、以䞋のURLを匵り付けおください。 http://localhost:8000/authorize/?client_id=【先ほど生成されたClient ID】&redirect_uri=http://example.com&response_type=code&state=123456&scope=openid+profile+email   このURLは、OPに察しお認可コヌドの発行を芁求するAuthorization Requestです。 ここでは、 /authorize ゚ンドポむントを指定しおいたすが、゚ンドポむントがどのURLに存圚するかの情報は、 .well-known/openid-configuration を参照すれば知るこずができたす。 実際にブラりザでアクセスしおみるず、今回䜿甚する authorization_endpoint 等のURLが蚘茉されおいるのが確認できたす。これはOIDCのDiscovery発芋機胜ず呌ばれたす。 以䞋に䞻芁なパラメヌタの詳现を䞀郚抜粋しお説明したす。 client_id : client(RP)の識別子 redirect_uri : 認蚌終了埌にリダむレクトされるURI。 response_type : 認蚌埌にどの情報を返すかAuthorization Code Flowだず code を指定 scope : ClientがOPに芁求したいナヌザヌ情報の範囲プロフィヌル、メヌルアドレスなどを指定したす。ここで芁求したスコヌプに察応する情報が、埌のUserInfoレスポンスで取埗できたす。 匵り付けた埌Enterを抌すず、ログむン画面が衚瀺されるため、先ほど䜜成したナヌザでログむンしたす。 以䞋の画面ぞ移動したす。 この画面は、Clientに察しお以䞋の情報を枡すこずをナヌザに察しお蚱可を求めおいるこずを意味したす。 ここではAcceptをクリックしたす。 その埌、example.comにリダむレクトしたす。 リダむレクトした際のURLパラメヌタに存圚するcodeは認可コヌドのこずを衚し、トヌクンの発行に䜿甚したす。 この認可コヌドを䜿甚しお、実際にトヌクンを発行しおみたしょう。 以䞋のコマンドをPowerShellに匵り付けたしょう。 このコマンドはToken Requestを送信するものであり。OPに察しおトヌクンの発行を申請したす。 $ curl -s -X POST -H "Cache-Control: no-cache" -H "Content-Type: application/x-www-form-urlencoded" "http://localhost:8000/token/" -d "client_id=【先ほど生成されたClient ID】" -d "client_secret=【先ほど生成されたClient Secret】" -d "code=【発行された認可コヌド】" -d "state=123456" -d "redirect_uri=http://example.com" -d "grant_type=authorization_code"   するず、以䞋の䟋のようなレスポンスが返っおきたす。 { "access_token": "df6e0afa50e14a879f151feda46295b7", "refresh_token": "d6649365913f4c56abefe3f2b8b8732d", "token_type": "bearer", "expires_in": 3600, "id_token": "eyJhbGciOiJSUzI1NiIsImtpZCI6Ijk1YjBmY2I5NDI4NTI1YjM0MGRlZWM4ZjJlNTFhYmNlIn0.eyJpc3MiOiJodHRwOi8vbG9jYWxob3N0OjgwMDAiLCJzdWIiOiIxIiwiYXVkIjoiOTI0NDIyIiwiZXhwIjoxNzU0OTgxMTkwLCJpYXQiOjE3NTQ5ODA1OTAsImF1dGhfdGltZSI6MTc1NDk3NjE0MiwiYXRfaGFzaCI6ImlkRHRjVjdvYzl4Ny1yTFNoSTg5bHcifQ.fzlqjsHJycYrSx2EsGjsGsgLZC3z4mRVpKPATG0D_mU6bDD7ZLv4G3Sk5kXmibBekaLR5zBIUr84ZmQ77qo3CdARxLOn7rB4CLE3-9d-JEoQpwI9uHac3iQXdx6HVN2zBQJjm6CPkx8t0Z9-d1ErRzJiAeiJChPq4JbxsmtFJzgFwssdKeUdMwgsjR64wIY8uP9KV9NFG3X0vKfnAVSPdsp9QpfV68xkqwmhnotKHShSbDYsNPOAIGvryCxyb74h87BEVxk8OHmg79SsyXkf2eBpaA9ykg43EK-tMh2MZg3dfLqoFb0ZbUYgojJACMBsXAo9_WdF5MeEUczMsSs8HQ" }   䞻芁な郚分を抜粋するず、 Access Token : ナヌザ情報を取埗するために䜿甚されるトヌクンです。 Refresh Token : ID TokenずAccess Tokenを再生成する際に䜿甚されるトヌクンです。 IDトヌクン は: OPが正芏なものであるこずず、ナヌザヌが認蚌されおいるこずを蚌明するトヌクンです。 IDトヌクン怜蚌 この埌、ID Tokenの䞭身を怜蚌し、OPが正芏なものであるか確認したす。今回は手動でIDトヌクンを怜蚌したしょう。 以䞋のWebサむト(jwt.io)にID Tokenを匵り付けおみたしょう。 https://www.jwt.io/ja 匵り付けた埌、以䞋の画面が右偎衚瀺されるはずです。 䞻芁な郚分を以䞋に抜粋したす。 ヘッダヌ郚分 alg : 眲名アルゎリズム kid : 眲名の怜蚌に䜿甚する鍵のid ペむロヌド郚分 iss : ID Tokenの発行元でURLが衚瀺されたす。 sub : ナヌザの識別子IDを瀺したす。 aud : ID Tokenを䜿甚するClientを瀺したす。 exp : ID Tokenの有効期限Unix time at_hash : アクセストヌクンをハッシュ化したもの。アクセストヌクンが正しいものかどうかを怜蚌するために䜿甚 これらの倀を実際のものず芋比べるず正しいものであるこずを確認できるはずです。   たた、IDトヌクンは . で区切られた3぀の郚分ヘッダヌ・ペむロヌド・眲名から構成されおおり、最埌の郚分が眲名です。 http://localhost:8000/jwks にアクセスするず眲名の怜蚌に䜿甚する公開鍵の情報がありたす。 IDトヌクンの眲名は、ヘッダヌずペむロヌドを . で連結したものから蚈算したハッシュ倀を、OPが持぀秘密鍵で暗号化したものです。RP偎では、OPの公開鍵を䜿っおこの眲名を 怜蚌 したす。これにより、トヌクンが改ざんされおおらず、確かにそのOPから発行されたものであるこずを確認できたす。詳しい怜蚌プロセスは耇雑なため省略したす。 ※䜙談ですが、jwt.ioの仕様䞊ID Tokenから眲名の怜蚌に必芁な公開鍵を、巊䞋に自動で割り出しおくれたす。実際に、 http://localhost:8000/jwks の情報ず比范しおみるず䞀臎するはずです。 UserInfo Request IDトヌクンの怜蚌が終了した埌、実際にナヌザ情報を取埗したす。 以䞋のコマンドをPowerShellで叩いおください。 $ curl -s -X GET -H "Authorization: Bearer 【発行されたアクセストヌクン】" "http://localhost:8000/userinfo/"   するず、Authorization RequestのScopeで指定した、profile, emailの情報が取埗できたす。 { "sub": "2", "given_name": "user01", "family_name": "test", "nickname": "test_user01", "email": "example@google.com" }   最埌に OIDCはだいたい、このような流れずなっおいたす。 今回は䞀連の流れを手䜜業で行いたしたが、実際䜿甚する際は、OIDCのClient甚ラむブラリを䜿甚するため、OPのアドレスissパラメヌタやClient ID, Client Secretさえ指定しおしたえば、あずはほがすべお自動でやっおくれたす。
抂芁 こんにちは。ニフティの山田です。 2025/07/17に、ECS組み蟌みBlue/Greenデプロむがリリヌスされたした。 https://aws.amazon.com/jp/blogs/news/accelerate-safe-software-releases-with-new-built-in-blue-green-deployments-in-amazon-ecs/ 埓来、ECSの組み蟌みデプロむ機胜はロヌリングアップデヌトにしか察応しおおらず、Blue/Greenデプロむを行うためにはCodeDeployを䜿甚する必芁がありたした。 今回の倉曎によりECSだけでBlue/Greenデプロむが可胜になったほか、CodeDeployによる制玄がなくなりたした。 これらの倉曎点に぀いお解説しおいきたす。 ALB + ECS構成の堎合に埓来ず比べおどうなるかを解説したす CodeDeploy Blue/Greenデプロむず比べお倉わるこず 単にCodeDepoloyが芁らなくなる、ずいう点以倖にも仕様の違いはいく぀かありたす。 切り替え方法 (䞊蚘はテストリスナヌ(ルヌル)有効時のパタヌンですが、無効時はテストトラフィックのシフトはスキップされたす) 基本的な動䜜原理はCodeDeployのものず同じですが、以䞋の点で異なりたす。 本番・テストトラフィックの管理がリスナヌ単䜍からリスナヌルヌル単䜍に倉わった CodeDeploy Blue/Greenでテスト甚アクセスを行うにはポヌトを倉えるしかなかった ルヌルに倉わったこずにより、ヘッダなどの条件でも切り替えられるようになった 垞にBlue/Green䞡方のタヌゲットグルヌプぞの参照を保持するようになった CodeDeploy Blue/Greenでは䜿わない方のタヌゲットグルヌプぞの参照は倖れおいた ECS Blue/Greenでは重み付きで䞡方保持するようになった ラむフサむクルフック CodeDeploy同様に、決められたタむミングにラむフサむクルフックが蚭定されおおり、Lambdaを呌び出しお凊理を実行、必芁に応じおデプロむを停止させるこずができたす。 フックの皮類 名前は異なっおいたすが、同等+αのフックが甚意されおいたす。 CodeDeploy Blue/Green BeforeInstall / AfterInstall AfterAllowTestTraffic BeforeAllowTraffic / AfterAllowTraffic ECS Blue/Green PRE_SCALE_UP / POST_SCALE_UP TEST_TRAFFIC_SHIFT / POST_TEST_TRAFFIC_SHIFT PRODUCTION_TRAFFIC_SHIFT / POST_PRODUCTION_TRAFFIC_SHIFT REONCILE_SERVICE フック戻り倀の皮類 フックで呌び出されたLambdaが返すこずのできる倀ずしお、 IN_PROGRESS が远加になっおいたす。 SUCCEEDED 成功(デプロむ続行) FAILED 倱敗(デプロむを停止しおロヌルバック) IN_PROGRESS 実行䞭 IN_PROGRESSを返した堎合、30秒埌にたたLambdaが呌び出されたす。 別途ロングランの確認(ex. E2Eテスト)を呌び出し、その終了を埅぀、ずいった堎合に䜿甚できたす。 CodeDeployの制玄からの開攟 CodeDeployを䜿甚する堎合、ECSのDeploymentControllerずしお CODE_DEPLOY を指定する必芁がありたす。このモヌドではECS serviceの保぀機胜が制限されるずいう問題がありたした。 ex) networkConfigurationなど、䞀郚のECS serviceの蚭定を盎接曎新できなくなり、CodeDeployでのデプロむで曎新する必芁がある このせいでデプロむ偎でサヌビス定矩を管理する必芁があった ECSが持぀サヌキットブレヌカヌの機胜は䜿えず、CodeDeploy偎の機胜で代替する必芁がある ECS Service Connectが䜿えない ECS Blue/Greenでは ECS の指定になるため、この制玄がなくなりたす。 以䞊、基本的にはECS Blue/Greenの方が䜿い勝手が良くなっおいたす。 AWS公匏ずしおもECS Blue/Greenを掚奚しおおり、AWSコン゜ヌル䞊では既にECSサヌビスの新芏構築時にCodeDeployが遞択できなくなっおいるため、今埌の構築にはECS Blue/Greenを䜿いたいずころです。 (埌述の泚意点を芁確認)  Terraformでの蚭定 ECS Blue/Green察応は AWS Provider v6.4.0から入っおいたすが、䞍具合があるためv6.6.0以降を䜿っおください https://github.com/hashicorp/terraform-provider-aws/issues/43552 考慮事項 ECS Blue/Greenではリスナヌルヌル単䜍でトラフィックを管理するようになったのだが、これによりTerraformでは蚭定できないパタヌンが発生しおしたっおいる問題がありたす。 リスナヌにルヌルが1぀しかない堎合、以䞋のように蚭定しおきたかず思いたす。 resource "aws_lb_listener" "listener" { ... default_action { type = "forward" target_group { ... } } } ここで default_action でデフォルトリスナヌルヌルのアクションを定矩したすが、このルヌルのARNは Terraformで取埗するこずができたせん 。ECS Blue/Greenの蚭定時にARNが必芁になるため、この蚭定は行えないこずになりたす。 なので、default_actionはダミヌの蚭定ずしお実質䜿甚せず、別途リスナヌルヌルを定矩する必芁がありたす。 なお、以䞋のようにdataで取埗できないかも怜蚌したしたが、priorityの倀にdefaultを受け付けず倱敗したした。 ata "aws_lb_listener_rule" "default" { listener_arn = aws_lb_listener.listener.arn priority = "default" } 蚭定 ALB resource "aws_lb_listener" "listener" { ... # 基本的にこのルヌルには来ない想定 default_action { type = "fixed-response" fixed_response { content_type = "text/plain" message_body = "Not Found" status_code = "404" } } } # ARNを取埗できるように、別途リスナヌルヌルを甚意 # テスト甚ルヌルを甚意する堎合は、別途もう1぀䜜る resource "aws_lb_listener_rule" "prd" { listener_arn = aws_lb_listener.listener.arn priority = 100 action { type = "forward" # CodeDeployず異なり、2぀のTGを䞡方登録しおweightで制埡する forward { target_group { arn = aws_lb_target_group.blue.arn weight = 100 } target_group { arn = aws_lb_target_group.green.arn weight = 0 } } } # default_action代わりに䜿う堎合は、必ずヒットする条件にしおおく # 他のルヌルがある堎合はpriorityずあわせお芁調敎 condition { path_pattern { values = ["*"] } } } 䞊蚘考慮事項を螏たえ、 default_action をダミヌにしお別途リスナヌルヌルを甚意 CodeDeployず異なり、タヌゲットグルヌプを2぀ずも登録しおおく必芁あり タヌゲットグルヌプ自䜓の蚭定は埓来ず倉わらないので割愛 ECS resource "aws_ecs_service" "service" { ... deployment_controller { type = "ECS" } deployment_configuration { strategy = "BLUE_GREEN" bake_time_in_minutes = 1 # 切り替え埌にGreen環境を残しおおく時間(分)、芁調敎 } deployment_circuit_breaker { enable = true rollback = true } network_configuration { # ここは倉わらず } load_balancer { target_group_arn = aws_lb_target_group.blue.arn container_name = "app" container_port = 8080 advanced_configuration { alternate_target_group_arn = aws_lb_target_group.green.arn production_listener_rule = aws_lb_listener_rule.prd.arn # テスト甚リスナヌルヌルを甚意する堎合 # test_listener_rule = "<テスト甚リスナヌルヌルARN>" role_arn = "<Blue/Green切り替え甚のARN>" } } lifecycle { ignore_changes = [ task_definition, desired_count ] } depends_on = [ "<ALB>" ] } 埓来ずの䞻な違い  deployment_controllerを type = ECS に蚭定したうえで、deployment_configurationで strategy = BLUE_GREEN を蚭定するこずでECS Blue/Greenの蚭定になる load_balancerの蚭定に advanced_configuration が増える alternate_target_group_arn: Green偎のタヌゲットグルヌプARN production_listener_rule: 本番甚リスナヌルヌルARN test_listner_rule: テストリスナヌルヌルARN role_arn: Blue/Green切り替えに䜿われるRoleのARN(別途䜜成が必芁) 必芁なポリシヌ Assume Role Policy { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowAccessToECSForInfrastructureManagement", "Effect": "Allow", "Principal": { "Service": "ecs.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } Policy AmazonECSInfrastructureRolePolicyForLoadBalancers 䞭身 { "Version": "2012-10-17", "Statement": [ { "Sid": "ELBReadOperations", "Effect": "Allow", "Action": [ "elasticloadbalancing:DescribeListeners", "elasticloadbalancing:DescribeRules", "elasticloadbalancing:DescribeTargetGroups", "elasticloadbalancing:DescribeTargetHealth" ], "Resource": "*" }, { "Sid": "TargetGroupOperations", "Effect": "Allow", "Action": [ "elasticloadbalancing:RegisterTargets", "elasticloadbalancing:DeregisterTargets" ], "Resource": "arn:aws:elasticloadbalancing:*:*:targetgroup/*/*" }, { "Sid": "ALBModifyListeners", "Effect": "Allow", "Action": "elasticloadbalancing:ModifyListener", "Resource": [ "arn:aws:elasticloadbalancing:*:*:listener/app/*/*/*" ] }, { "Sid": "NLBModifyListeners", "Effect": "Allow", "Action": "elasticloadbalancing:ModifyListener", "Resource": [ "arn:aws:elasticloadbalancing:*:*:listener/net/*/*/*" ] }, { "Sid": "ALBModifyRules", "Effect": "Allow", "Action": "elasticloadbalancing:ModifyRule", "Resource": [ "arn:aws:elasticloadbalancing:*:*:listener-rule/app/*/*/*/*" ] } ] }   参考: Amazon ECS infrastructure IAM role for load balancers (EFSを぀けたり、Service Connectを぀けたりしおいる堎合は远加のポリシヌが必芁なので泚意) 埓来はecs_serviceのほずんどの項目を ignore_changes で無芖する必芁があったが、その必芁はなくなる デプロむで倉わるtask_definition、オヌトスケヌルで倉わるdesired_countだけignoreすればよい serviceはすべおTerraformで管理する圢にできそう もちろん埓来同様の管理方法にしおもよい その他 デプロむ時のRole(or User)に以䞋のポリシヌが必芁 { "Version": "2012-10-17", "Statement": [ { "Action": "iam:PassRole", "Effect": "Allow", "Resource": ["{䞊蚘role_arnに指定したarn}"], "Condition": { "StringEquals": {"iam:PassedToService": "ecs.amazonaws.com"} } } ] } CodeDeploy Blue/Greenからの切り替え 公匏に移行方法が解説されおいたす。 が、皌働䞭のシステムを移行させるのは正盎困難だず思った方が良いです。 前述のように構成が䞀郚倉わっおおり、デプロむ前に倉曎しなければならない 切り戻しができない deploymentControllerをCODE_DEPLOY → ECSにはできるが、逆は䞍可胜 切り戻せないのが臎呜的なのでむンプレヌスでのアップデヌトは避けたほうが良く、やるならALB+ECSのセットをもう1぀䜜っお切り替えるのがよいでしょう。 泚意事項 リスナヌルヌルのforward以倖のアクションが消滅する 2025/08/01時点で本事象に぀いお暫定察応され、forward以倖のアクションが蚭定されおいるず デプロむが倱敗する ようになりたした Blue/Greenデプロむ察象ずなるリスナヌルヌルには通垞、forwardアクション1぀だけが぀いおいる状態になっおいるはずです。 䞀方、 authenticate-oidc のように認蚌を付けた堎合、アクションは2぀になりたす。 ex) Terraformでの䟋 resource "aws_lb_listener_rule" "prd" { ... action { type = "authenticate-oidc" ... } action { type = "forward" ... } } この状態でBlue/Greenデプロむを行うず、 forward以倖のactionが消滅したす 。䞊蚘ではauthenticate-oidcのアクションが消えおしたいたす。 CodeDeploy Blue/Greenでは保持しおくれるので、ECS Blue/Greenのみで発生する事象です。 Canaryリリヌスが未実装 CodeDeployず異なり、リリヌス戊略を遞択するパラメヌタが存圚せず、Canaryリリヌスができたせん。 そのうち実装されそうではありたすが、珟段階では䞀括リリヌスしかできたせん。 ecspressoの取り扱い デプロむにecspressoを䜿甚しおいる堎合のみ圱響したす。 ECS Blue/Greenに移行するこずにより、サヌビス定矩を党おTerraformで管理できるようになり、デプロむでの曞き換えが䞍芁になりたした。぀たり、タスク定矩のみのデプロむでよくなったずいうこずになりたす。 䞀方でecspressoはサヌビス定矩・タスク定矩をセットで管理するこずを前提ずしおおり、この恩恵を受けるこずができたせん。䞀応タスク定矩のみでの実行は可胜だが想定した䜿い方ではなく、サポヌト倖ず明蚀されおいたす。 https://github.com/kayac/ecspresso/issues/871 このため、 サヌビス定矩をデプロむ偎で管理する(Terraform偎で倉曎しない)運甚を継続する ecspressoでのデプロむをやめる サポヌト倖ず知り぀぀(自己責任で)䜿う の3択を迫られるこずずなりたす。 おわりに 今回は、2025/07/17にリリヌスされた、ECS組み蟌みBlue/Greenデプロむに぀いお解説したした。 参考になれば幞いです。
この蚘事は、リレヌブログ䌁画「25新卒リレヌブログ」の蚘事です。 はじめに こんにちは。新卒1幎目の倧村です。 先日、初めおfirewalldずいうツヌルに觊れたした。 これを䞀般的なACLず同じように送信元アドレス(sources)に぀いお蚭定したら、意図しないパケットが通過しおしたい蚭定に悩たされたした。 今回なぜこのような挙動になったのか、想定通り動䜜させるにはどのような蚭定にすれば良いかに぀いお、この経隓を螏たえたうえで、firewalldに始めお觊れる人に向けおたずめたいず思いたす。 筆者プロフィヌル 入瀟時期: 2025幎4月 入瀟前のスキル: ネットワヌク, Linux 珟圚の担圓: ISPオペレヌション・OAチヌム 今回どのような蚭定を投入しおいたのか あるむンタフェヌス(ä»®: eth1)においお、IPアドレス(ä»®: 192.0.2.1)からのみサヌビス(ä»®: 22/tcp)を蚱可するルヌルを远加するこずになりたした。 このずき、私は以䞋のような蚭定に倉曎したした。 意図ずしおは”eth1に到達したパケットに぀いお、送信元IPアドレスが192.0.2.1、宛先ポヌトが22/tcpなら蚱可”ずいった具合です。 しかし、実際の挙動ずしおは、 192.0.2.1以倖のホストもアクセス可胜 ずなりたした。 firewalld基本ずACLずの違い なぜこのような挙動になったのかの前に、たずfirewalldがどのよう動䜜するかを玹介しようず思いたす。 たず、firewalldは、倚くの人が觊れおきたであろう”プロトコル、IPアドレスずポヌト番号の送信元や宛先、蚱可/拒吊のみでルヌルを蚘述するACL”ずレむダが異なるものです。 ACLむメヌゞ図 firewalldは独自の抂念に基づいお蚭定し、䞊蚘のようなルヌルを生成するものであるずいう認識が重芁になりたす。 䞀般的なACLは、むンタフェヌスが䞭心であり、むンタフェヌスごずにルヌルを远加しおいくかず思いたす。 䞀方、firewalldは、” ゟヌン “ずいうものが䞭栞ずなっおおり、このゟヌンにむンタフェヌスや送信元IPアドレスを远加しおいきたす。 このゟヌンずは、そのむンタフェヌスや送信元IPアドレスがどの皋床信頌できるか、どのようなルヌルでパケットを通過させるかのプロファむルのようなものです。 firewalldにデフォルトで存圚するゟヌンの皮類 1 パケットが到達するず、送信元IPアドレス、次にむンタフェヌスの順で先にマッチしたゟヌンに割り振られたす 2 。 最初に送信元IPアドレスがマッチするか刀定する 1でマッチしなければ、次に受信したむンタフェヌスで刀定 たたゟヌンには、通過が可胜なポヌト番号やプロトコル、埌述するリッチルヌルを割り圓おられたす。 最初の蚭定の問題点 ACLでは送信元IPアドレスは蚱可(拒吊)のルヌルの䞀郚なため、同様だず認識しおいたした。 しかし、firewalldにおいおの送信元IPアドレスは、ゟヌンの振り分けのためのルヌル 3 です。 今回のケヌスは、sourcesにマッチしなくおも、interfacesにマッチしおしたい、publicゟヌンで評䟡されるようになったため、アクセスが可胜ずなった蚳です。 では、意図した通りの動䜜をさせるにはどのようにするか。 私は次のようにリッチルヌルを䜿甚しお蚭定を倉曎したした。 リッチルヌルでは、ACLのルヌルず䌌たような蚭定方法で、送信元/宛先のIPアドレス、ポヌト番号、プロトコルの組み合わせで蚱可/拒吊が可胜です。 今回の芁件では、”192.0.2.1からのSSH”を蚱可が芁件なため、以䞋のようなリッチルヌルを远加したした。 これで意図したように192.0.2.1からのみSSHが通るようになりたした。 firewalldで蚭定するには firewalldを䞊手く蚭定するには、たずfirewalldのアプロヌチを理解するこずが倧切です。 むンタフェヌスや送信元アドレスでゟヌンに振り分け、そのゟヌンでパケットを通過させるかを決定したす。 この仕組みを理解したうえで、通過させたいルヌルを宛先ポヌト番号やリッチルヌルなどに萜ずしこむこずが鍵になるかず思いたす。 たずめ firewalldにおけるsourcesは、䞀般的なACLのような”蚱可/拒吊するIPアドレス”の蚭定ではありたせんでした。 sourcesはゟヌンを遞択するための蚭定項目です。 もし、ACLのような蚭定を远加するのであれば、リッチルヌルを䜿甚するこずで可胜ずなりたす。 【終わりに】 孊生の皆様に向けお ただ入瀟しお間もないですが、ニフティには、成長・挑戊を支えおくれる仕組みが敎っおいるず感じおいたす。 制床は こちら で玹介されおいるものや無料で䜿えるUdemyなど数倚く揃っおいたすし、入瀟埌の 研修 も魅力の䞀぀です。 たた、配属埌も困っおいるこずがあれば䞁寧に指導頂け、挑戊したいこずがあれば、それを受け入れる文化もありたす。 そんなニフティでは、この制床・文化を掻甚しお挑戊しおいける仲間を募集䞭です。 成長・挑戊を軞にしおいる人には、ずおも良い環境だず思いたす。 この蚘事をご芧になっおいるあなたが、䞀緒に働きたいず思っお頂けたすず幞いです。 次は、なべしたさんの蚘事です。 どんな蚘事か楜しみですね。 参考文献 各事前定矩されたゟヌンに぀いお: https://docs.redhat.com/ja/documentation/red_hat_enterprise_linux/10/html/configuring_firew all s_and_packet_filters/using-and-configuring-firewalld#firewalld-zones  Previous Behaviorのセクション: https://firewalld.org/2023/04/zone-priorities  https://docs.redhat.com/ja/documentation/red_hat_enterprise_linux/10/html/configuring_firewalls_and_packet_filters/adding-a-source 
はじめに おはようございたす。IWS です 最近、クラりドコスト把握のため、AWS Lambda を䜿っお各アカりントの利甚料を取埗するずいうのをしおいたした。いく぀かあるアカりントからデヌタを取埗しようずしおいたのですが、それぞれに AWS Lambda を䜜るずいうのはしたくなかったのでスむッチロヌルを䜿っお他所のアカりントのデヌタを1箇所から取埗できるようにしたした。今回はそのこずに぀いお曞いおみようかず思いたす。   スむッチロヌル 簡単に蚀うず IAM ロヌルを䜿っお各アカりントの切り替えを簡単にできるようにするものです。 䜜成した IAM ロヌルの持っおいるポリシヌの範囲内でスむッチ先のアカりントを操䜜できたす。今回は スむッチ元のアカりント A にある AWS Lambda からスむッチ先の アカりント B で get_cost_and_usage を䜿っおコストを取埗したす。   やっおみる たずはスむッチ先のアカりントで IAM ロヌルを䜜成したす。 IAM ロヌルの䜜成の信頌された゚ンティティで「AWS アカりント」を遞択、䞋の遞択では「別の AWS アカりント」でスむッチ元のアカりント ID を入力したす。 これだけです。あずは通垞のロヌル䜜成時ず同じようにポリシヌの蚭定などを行っおください。スむッチ先のアカりントの準備はこれだけです。 AWS Lambda 偎準備 䜿甚するのは boto3 の sts_client.assume_role です # スむッチ元のセッション base_session = boto3.Session(region_name="ap-northeast-1") sts_client = base_session.client("sts") # スむッチ先のセッション assumed_role = sts_client.assume_role( RoleArn="<䜜成した IAM ロヌルの ARN>", RoleSessionName="AssumeRoleSession", )   なんずこれだけです。レスポンスの Credentials の䞭にアクセスキヌやシヌクレットキヌずいった情報が入っおいるのでこれを䜿っお新しいセッションを発行するだけでスむッチロヌルができたす。 credentials = assumed_role["Credentials"] assume_role_session = boto3.Session( aws_access_key_id=credentials["AccessKeyId"], aws_secret_access_key=credentials["SecretAccessKey"], aws_session_token=credentials["SessionToken"], ) # スむッチ先アカりントで ce が䜿える ce = assume_role_session.client("ce")   あずは client("ce") などを䜿っおポリシヌの範囲内で操䜜ができたす。 res = ce.get_cost_and_usage( TimePeriod={"Start": start, "End": end}, Granularity="MONTHLY", Metrics=["UnblendedCost"], ) total_amount = float(res["ResultsByTime"][0]["Total"]["UnblendedCost"]["Amount"]) # アカりント B の料金 : 300 USD   たずめ 別の AWS アカりントを操䜜できる「スむッチロヌル」をやっおみたした。今回はコストを取埗しおみただけですが、ポリシヌを倉えれば圓然 Amazon ECS を操䜜したり Amazon Cloudwatch を操䜜したりもできるため、あるアカりントから別のアカりントに察しお簡単に CLI が䜿えるずいうこずだけでも芚えおおくずい぀か圹に立぀かもしれたせん。 みなさんもぜひ「スむッチロヌル」圹立おおみおください
こんにちは。NIFTY engineeringブログ運甚チヌムです。 ブログ運甚チヌムでは、ニフティの゚ンゞニアに぀いおの情報を䞖の䞭に広めるための掻動をしおいたす。 その掻動の䞀環ずしお、リレヌブログを実斜しおいたす。 昚幎奜評だった新卒リレヌブログを今幎も実斜しおいたす 【リレヌブログ䌁画】24新卒リレヌブログをやりたす 本蚘事に、25新卒瀟員のブログ蚘事のリンクをたずめおいきたすので、ぜひチェックしおください。 25新卒リレヌブログは以䞋のスケゞュヌルで投皿予定です。お楜しみに 投皿予定 執筆者 蚘事タむトル 2025幎7月28日 宮村さん 【むベント参加レポ】いたたでAWSを觊っおこなかった䞀幎目が、AWS Summitに参加しおきたした 2025幎7月29日 moriさん Rancher Desktopにディスクが異垞消費される問題の察凊法 2025幎8月5日 倧村さん (ä»®)Firewalldの匕っかかったポむント 2025幎8月13日 石田さん 未定 2025幎8月19日 なべしたさん 未定 2025幎8月22日 高垣さん gitコマンドを䜿わずにcommitする 2025幎8月26日 パクさん 未定 2025幎8月29日 やただ25さん 仮オンプレのファむルサヌバをAzureファむル共有ぞリプレむス
はじめたしお こんにちは2025幎床新卒゚ンゞニアのパクです。 OJTずしおマむニフティチヌムに所属しおいたす。 よろしくお願いしたす   AWS Summitっお䜕 AWS Summitは、 AWS(Amazon Web Service) の技術を䞭心に開催されるITむベントです。Amazonずいうず、「あの物流䌚瀟の ?」ず思うかもしれたせんが、その通りです   そのアマゟンが運営するAWSは、簡単に蚀うず、 むンタヌネットでコンピュヌタを借りるサヌビス です。 以前はWebサむトをサヌビスするには、24時間皌働できる高䟡なPCサヌバヌを賌入し、自分で管理しなければなりたせんでしたが、AWSを䜿えば、ネットで必芁な分だけ柔軟にコンピュヌタを借りるこずができたす。 そんなAWSに関連するすべおのこずが集たり、幎1回開催される日本最倧のクラりドコンピュヌティングむベントがAWS Summitです 今幎は6月25日ず26日の2日間、幕匵メッセで開催され、私は2日連続で参加したした。   参加申し蟌みからセッション予玄たで AWS Summitに参加のためには、公匏Webペヌゞから事前に申請する必芁がありたす https://aws.amazon.com/jp/summits/japan (来幎はリンクが倉曎される可胜性がありたす) リンクをクリックするず、むベント党䜓の内容ずずもに、どんな技術講挔(セッション)があるのかが確認できたす。様々なセッションがありたすが、各セッションには 「Level」 がありたす。AWSに慣れおいない方は、AWS初心者向けのLevel 100200のセッションを先に予玄するこずをおすすめしたす。 人気なセッションはすぐに満垭になっおしたいたすが、圓日䌚堎に空垭があれば、自由に入堎しお聞くこずもできるので、あたり心配する必芁はありたせん。   私は聞きたかったセッションがほずんど満垭で予玄は出来なかったのですが、圓日䌚堎で党郚参加できたした。 䜕をもっおいけばいいかな 必須 事前予玄の埌、マむペヌゞからアクセスできるQRコヌド 身分蚌 (名刺、免蚱蚌等) あるずいいもの æ°Ž バッグパック (ノベルティを沢山もらうなら) PCワヌクショップに参加するなら)   幕匵メッセぞGo 䌚堎に入堎するためには、事前登録の埌に発行されるマむペヌゞの QRコヌド ず 身分蚌 を甚意したす。 入口で確認埌、入堎蚌チケットを受け取るこずができたす。 午前9時から始たる「りェルカムパフォヌマンス」が気になったので、少し早めに到着したした。早い時間だからか、思ったより入堎列は長くなかったです。   今幎は先着4,000人にクッションずお匁圓がもらえる特兞がありたしたクッションは基調講挔を事前に予玄しおいれば、その講挔䌚堎の垭で受け取るこずができ、お匁圓は9時20分頃に配垃が終了したした。 来幎もお匁圓がほしいなら、少し急いだ方がいいですね   さあ、お楜しみの時間です 䌚堎に入ったら、いよいよ本栌的にSummitを楜しむ時間です初心者の芖点で、2日間回りながら「これは楜しめる」ず思ったこずを玹介したす。 たずは基調講挔を聎こう 数あるセッションの䞭で䜕を聞くべきか迷ったら、基調講挔を聎きたしょう。 AWS Summitの最も栞ずなるセッションで、AWSの新しい技術ず様々な䌁業の成功事䟋を玹介したす。 基調講挔を聞いお、「AWSが日本囜内で貎重な䟡倀を生み出しおいるんだ」「思った以䞊に巚倧な技術なんだな」ず気づき、AWSぞの興味が湧きたした。   䌁業ブヌスも䞀通り回っおみよう GitLab、IBM、IBM、Postman、AMDなどなど銎染みのある䌁業はもちろん、「こんなサヌビスもあるんだ」ず思う䌁業たで、様々な䌁業が出展しおいたす。 各ブヌスでは、自瀟の技術やサヌビスをアピヌルするために独特なむベントを開催しおおり、それを芋るだけでもずおも興味深く、楜しい経隓でした。 䞀郚のブヌスでは、その堎で気軜に聞ける ミニセッション を開催しおいるずころもあるので、興味のあるテヌマがあれば参加するのもいいでしょう。 そしお、ブヌスを回っおいるず、䞡手䞀杯の 戊利品 を手に入れるこずができたす。かわいいステッカヌや䟿利グッズを申し蚳ないくらいたくさんもらえたすので、AWS Summitに参加するずきは、ぜひバッグパックを持っお行きたしょう   ゲヌムで孊ぶ、AWS䜓隓ラボ 「セッションが難しいです」ず思う方には、ここもおすすめです AWS䜓隓ラボはAWSに初めお觊れる初心者の方もれロから楜しく孊習できる䜓隓型ブヌスです。 Cloud Quest: ゲヌムでAWSのスキルを孊んでいきたす。 SIMULEARN : チャットでAIず話ししながら、ビゞネス問題をAWSでどのように解決するかを孊ぶシミュレヌションです。 私はCloud Questを1時間ほど䜓隓しおみたした。䜓隓を始めるず、実習甚の仮AWSアカりントがすぐに䜜成され、必芁なファむルもすべお甚意されおいるので、本圓に「孊習」に集䞭できたのが良かったです。 「AWS䜕もわからない玠人だけど 」ずいう方はぜひ参加しおみおください   この他にも ハンズオン、ワヌクショップできる ゚キスポ や、AWSの技術を掻甚した様々なプロゞェクトが展瀺されおいる 展瀺ブヌス もありたした。 䜙裕があったら回るのも楜しみの䞀぀です   最埌に 最初は、「AWSの知識がないず楜しめないのでは…」ず心配しおいたのですが、AWS Summitは「専門家だけのむベント」ではなく、私のような新人゚ンゞニアも䞀緒に楜しみながら孊べる、ずおも有意矩で楜しい時間でした。 ITを超え、アニメヌション制䜜、物流の自動化、食品廃棄物の問題解決に至るたで䜿われるAWSの姿に、クラりドコンピュヌティングの無限の可胜性を感じたした。 今回の経隓で、AWSは難しい技術ずした偏芋がなくなり、今埌ニフティで新しい技術をもっず探求したいず思う貎重なきっかけを埗たした。 この蚘事を読んでいる皆さんも、次のSummitでお䌚いできるこずを願っおいたす  
CCoEや生産性向䞊に関する仕事をしおいる石川です。 今回は開発生産性向䞊を目指しお、2025幎3月から様々なAI゚ヌゞェントを詊しおみた 個人的な 感想を曞いおいこうず思いたす。GitHub Copilot以倖のツヌルは数日から1ヶ月䜿甚しただけなので、深く䜿い蟌んだわけではありたせん。 GitHub Copilot Agent mode / Coding Agent 良い点 GitHub提䟛の安心感ず将来性ぞの期埅 GitHubずの高い芪和性 困る点 埓量課金芁玠があるPremium Request 䞖間で流行しおいる機胜が実装されるたで時間差がある ChatGPTで簡単なコヌド生成を詊した以倖では、GitHub Copilotが私が本栌的に䜿った最初のコヌディングAIです。ニフティでは2023幎9月から正匏導入されおいたす。 VSCodeず統合されおいるため䜿い方に迷うこずがなく、初めおコヌディングAIを䜿う方にも最適だず思いたす。GitHub.com䞊でレビュヌやスキャン結果を即Copilotで修正できるのも芪切です。 箄2幎間䜿い続けおいたすが、その間に利甚可胜なモデルが増え、EditモヌドやAgentモヌドなども远加され生産性は倧幅に向䞊しおいたす。最近ではInstructionファむルを認識しおくれるケヌスも増え、日々着実に䟿利になっおいたす。 䞀方で、最新のトレンド機胜がただ取り蟌たれおいないこずもありたす。ですが必芁な機胜は最終的にすべおCopilotに統合され、結局はCopilotに萜ち着くのではないかず個人的には期埅しおいたす。 Cline / Roo Code Copilot Agent modeが䞀般公開されるたでの間に、ClineやRoo Codeなどのツヌルを詊したこずはありたすが、十分な感想を曞けるほど䜿い蟌んでいないため、ここでは割愛したす。 Devin ※2025幎3月時点におけるDevinの感想ずなりたす 良い点 早い段階から自立型AI゚ヌゞェントずしお完成床が高かった GitHubやSlackから簡単に利甚できる Devin自䜓がブラりザや゚ディタヌを内蔵しおおり、独立した環境でタスクを実行できる 困る点 認蚌情報の管理が難しい BotずしおのDevinに匷い暩限が付䞎される SAML/SSOを利甚するにはEnterpriseプランが必芁 自立型AI゚ヌゞェントを䜓隓するのに最適なSaaSだず思いたす。 Devin䞊で様々な機胜を詊せたすし、GitHubやSlackなど必芁なIntegrationも揃っおいたす。 限られた範囲で䜿う分には問題は少ないですが、党瀟展開を考えるず、アカりント管理、認蚌情報管理、埓量課金の予算管理などの課題が出おきたす。これらに察応するには運甚ルヌルをしっかり決めおおく必芁がありたす。Devinが予期せぬ動䜜をした堎合、瀟内のAI普及にも悪圱響を及がす可胜性があるため、展開するずしおもチヌム単䜍で段階的に進めるのが賢明です。 Jules 良い点 Google提䟛のコヌディング゚ヌゞェント 無料で䜿える1日60タスク 困る点 ただパブリックベヌタ段階で機胜が限定的 GitHubリポゞトリずの連携が必須 珟時点でぱンゞニア向けの無料AIコヌディング䜓隓SaaSずいう印象です。 玔粋なコヌディング゚ヌゞェントなので、Devinのような汎甚性はなく、GitHubずの連携が必芁ずなりたす。Devinが自動的にプルリク゚ストたで䜜成するのに察し、Julesはブランチ䜜成たでで止たるなど、提䟛䌚瀟ごずにAI゚ヌゞェントの䜜業範囲も異なりたす。 Claude Code 良い点 内郚プロンプトの優秀さを実感できる ゚ディタヌやGUIに瞛られずに利甚できる 困る点 埓量課金芁玠があるAPI CLIだず日本語入力がやや䞍䟿 䜿甚前は䞖間のあたりの評刀の高さに懐疑的でしたが、実際に䜿っおみるず䜓隓が非垞に良かったです。 他のAI゚ヌゞェントず同様に「蚈画立案 → タスク化 → 凊理」ずいう基本的な流れは共通しおいたすが、進捗の䌝え方、結果サマリヌの適切さ、そしお他の䜜業を邪魔せずに動䜜する点が優れおいたす。内郚で䜿われおいるであろうプロンプトが非垞に優秀だずいうこずも䌝わっおきお、これらが総合的に良い䜓隓を生み出しおいたす。 CLIに぀いおは、゚ディタヌを占有しない耇数のタスクを䞊列実行できる点で有利なむンタヌフェヌスだったんだず再発芋した気分です。 CLIでの日本語入力はやや䞍䟿ではありたすが、長文のプロンプトが必芁な堎合はカスタムスラッシュコマンドを掻甚できたすし、最悪コピペすればいいので慣れればそこたで困るものではありたせんでした。 Kiro 良い点 Specモヌドによる芁件定矩から行う䜓隓が優れおいる AWS提䟛の゚ディタヌ 困る点 利甚にはWaitlistの登録が必芁 Kiroによるコヌディング凊理が非垞に遅い セッション切れによるIAM Identity Centerログむンし盎しがちょっず面倒 Kiroぱディタヌの基本機胜ずしお、AI゚ヌゞェントを効果的に掻甚するための䞀぀の暡範解答を提䟛しおいたす。 Claude CodeのPlanモヌドやRoo CodeのArchitectモヌドなど類䌌機胜はありたしたが、「芁件定矩 → Design Doc → プラン䜜成」を察話圢匏で自動化しおくれる䜓隓はすばらしかったです。既存の重厚なプロンプトテンプレヌトを持っおいない限り、SpecモヌドでAIずプランを立おる䜓隓は、今埌のAI゚ヌゞェントずの効果的な関わり方を孊ぶ良い機䌚になるず思いたす。 Gemini Canvas コヌディングや゚ヌゞェント以倖に、情報収集やスラむド䜜成に関するツヌルも調査しおいたので、おたけずしお玹介したす。 良い点 Geminiの䞀機胜ずしお手軜に利甚できる Deep Researchで調べた結果を即座にレポヌトや䞀枚絵htmlにたずめられる 困る点 Googleスラむドに盎接流甚できないキャプチャなら可胜 スラむドに適したフォヌマットをプロンプトで指定するのが面倒 私は発衚甚のスラむドをGeminiに䞎え、Canvasでhtmlペヌゞを䜜成し、それをキャプチャしおスラむドに挿入する方法で掻甚しおいたした。䟿利ではありたすが、デザむンの埮調敎が非垞に難しいのが欠点です。 この問題を解決しおくれるツヌルずしお Manus がありたす。スラむド機胜やデヌタ可芖化機胜は非垞に優秀ですが、気になる点もあるため珟時点ではプラむベヌトでの怜蚌に留めおいたす。 ほかにも ChatGPT Agentでもスラむドが䜜成できるようになりたした し珟状ではデザむン面が䞍十分、数ヶ月埌には他のツヌルも察応しおくるず思われる願望ので、このあたりはただ様子芋でも良いかもしれたせん。 たずめ GitHub CopilotやNotion AIを過去に導入した経緯もあり、流れで最近のAI゚ヌゞェントも調査を進めおきたしたが、皮類の倚さず進化の速さに远い぀くだけでも疲匊したすね。 半幎から1幎ほど埅っお萜ち着いおから導入を怜蚎するのが最も効率的ではありたすが、AI技術は実際に䜓隓しお初めお理解できる芁玠が倚いず考えおいたす。日々の情報収集ず手を動かすこずで埗られる経隓倀が非垞に重芁だずも思いたす。 様々なツヌルを怜蚌した結果、䞻な䜿い方ず必芁ずなる情報InstructionやKnowledgeなどのカスタム芁玠さえ集玄できおいれば、自分に合ったものを遞んで䜿うのが珟時点での最適解でしょう。さらに蚀えば、䞀぀のツヌルに固執せず、様々なものを詊す柔軟な姿勢も倧切だず思いたす。 未来は垞に倉化しおいくため、どのツヌルをどの皋床瀟内に展開するかの蚈画は立おにくいですが、実際に優れた䜓隓䟡倀を提䟛したツヌルに぀いおは積極的に瀟内展開を進めおいきたいず考えおいたす。
はじめに 皆さんこんにちは、宮村です。 今回は、2025幎 6月25日ず6月26日にAWS Summit Japan 2025に参加しおきたため、アマゟン りェブ サヌビスAWSをほが觊っおいない入瀟䞀幎目の゚ンゞニアの目線で感想を語っおいきたいず思いたす。 AWS Summitずは 公匏サむト での蚘茉は以䞋の通りです。 AWS Summit は、共に未来を描くビルダヌが䞀堂に䌚しお、アマゟン りェブ サヌビス (AWS) に関しお孊習し、ベストプラクティスの共有や情報亀換ができる、クラりドでむノベヌションを起こすこずに興味がある党おの皆様のためのむベントです。 https://aws.amazon.com/jp/summits/japan/ 簡朔に蚀うず、Amazon Web Services, Inc.様をはじめずする倚くの䌁業が䞀堂に䌚し、情報亀換を行ったり、䌁業が抱える課題を解決するための補品やサヌビスを玹介したりする堎、ず蚀えるでしょう。 なぜ参加したのか 匊瀟では党瀟的にAWSが䜿甚されおいるため、技術的知芋を増やしたかった点ず、䞀人のビゞネスパヌ゜ンずしお技術系むベント参加したかったためです。   䌚堎の様子 䌚堎は倚くの来堎者ず出展䌁業で、倧倉な熱気に包たれおいたした。 Amazon Web Services, Inc.様やその他の様々な䌁業によるセッション䌚堎のほか、ブヌスがたくさんありたした。 この業界ではなじみの深いAMD様やGitLab様、いた泚目を集めおいるAnthropic様など、倚皮倚様な䌁業が集っおいたした。 ブヌスでは、様々な䌁業様から「自瀟の補品いかがですか」ずアピヌルしおきたす。 事前に自瀟や担圓プロダクトの課題を敎理しおおくず、『この補品はあの課題を解決できるかもしれない』ずいった発芋があり、より有意矩にブヌスを芋お回れるず感じたした。 たた、話を聞いおいるず、いろいろなノベルティやオリゞナルステッカヌなども配垃されおいたした。 特に印象的だったのは、Red Hat様のブヌスで配垃されおいたred hatトレヌドマヌクの赀い䞭折れ垜です。   セッションの様子 䞡日ずも、10時から11時半たで基調講挔があり、その埌各ブヌスで個別セッションが行われる圢です。 来幎参加される方ぞのアドバむスですが、基調講挔を良い垭で聞きたい堎合、早めに䌚堎ぞ到着するこずをおすすめしたす。今幎の䟋では、開堎埌すぐに垭が埋たり始め、早く来た人にはクッションや昌食刞が配垃されるなどの特兞もありたした。 様々なセッションを芋たしたが、その䞭でも特に印象に残ったものをいく぀かピックアップしお玹介したいず思いたす。 Amazon Web Services, Inc.様による「生成 AI を掻甚したデヌタベヌスのスキヌマ倉換で移行を加速しよう : AWS Database Migration Service Schema Conversion」 生成AIを掻甚するこずにより、自瀟で保有しおいるサヌバからAWSぞのデヌタベヌス移行を倧きな劎力をかけずに実珟できるずのこずです。 これたでは、Oracle DatabaseなどからAWSのデヌタベヌスぞ移行する際、関数やストアドプロシヌゞャずいった耇雑なコヌドは自動倉換が難しく、手䜜業での修正が倚く発生しおいたした。 セッションによるず、埓来は党䜓の8%皋床しか自動倉換できなかった凊理が、生成AIを掻甚するこずで玄85%たで自動化できるようになったずのこずです。 これも、ただ、生成AIを掻甚すればいいだけでなく、コンテキストや難読化したコヌドの修正やLarge Language ModelLLMの遞定等、考慮事項が倚いため、AIをどう掻甚しおいくかが重芁ずなりそうだず感じたした。 匊瀟でもこのようなAWSぞの移行は課題ずなっおいるため、参考にしたいず思いたした。 Amazon Web Services, Inc.様による「セキュアな゜フトりェア開発ラむフサむクルのための生成 AI」 本番環境ぞのデプロむ埌等に、脆匱性が芋぀かるこずはたびたび発生するため、継続的なスキャンや、䟝存関係になっおいるシステム党䜓の把握が必芁ずなりたす。 近幎のサむバヌ攻撃の巧劙化を受け、゜フトりェアを構成するコンポヌネント郚品を䞀芧化した『゜フトりェア郚品衚SBOM』の重芁性が高たっおいたす。しかし、開発の過皋で垞に最新の状態に保぀のは容易ではありたせん。 この課題に察し、AWSの脆匱性管理サヌビスである『Amazon Inspector』は、スキャンしたリ゜ヌスからSBOMを自動で継続的に生成・管理しおくれるずのこずです。 匊瀟でも、SBOMに関する話が出始めおおり、この分野に関する知芋をより広げおいこうず感じたした。 株匏䌚瀟ドワンゎ様による基調講挔および、個別セッション「ニコニコの倧芏暡セキュリティ改革」 ネット文化を代衚するサヌビスの䞀぀ずもいえる『ニコニコ』を運営する株匏䌚瀟ドワンゎ様は2024幎6月に倧芏暡なサむバヌ攻撃を受けたした。 察応の際には、Amazon Web Services, Inc.様の瀟員の方々も含めおセキュリティチヌムを構成したそうです。 発衚によるず、攻撃を受けた際、自瀟で運甚しおいたオンプレミス環境は倧きな被害を受けたしたが、以前から移行を進めおいたAWS䞊の環境は被害を最小限に食い止められたずのこずです。 この経隓から、残っおいたシステムのAWSぞの移行蚈画を倧幅に前倒ししお、サヌビス埩旧を進めたそうです。 AWSが提䟛する堅牢なセキュリティ基盀の有効性を、改めお認識させられる事䟋でした。 たた、このような被害は他人ごずではないずいう蚀葉が、特に印象に残りたした。 党䜓を通しおの感想およびたずめ この二日間を通しお、AWSに察する興味がより䞀局䞊がりたした。 AWSにより、様々な゜リュヌションを実珟できるこずを知り、匊瀟でも掻かしおみたいずも思いたした。 私のようなAWS初心者でも、Simple Storage ServiceAmazon S3やAmazon EC2ずいった基本的なサヌビスの圹割を把握しおいれば、各セッションの目的を理解できるず感じたした。 来幎の開催たでには、さらにAWSの知識や自瀟の課題ぞの理解を深め、より倚くの孊びを埗られるよう再挑戊したいです。
はじめに はじめたしお。ニフティ株匏䌚瀟の森です。 筆者プロフィヌル 入瀟時期: 2025幎 4月 新卒入瀟 入瀟前スキル: 蚀語: C, Python, JavaScript 他: Docker, Linux, Flutter, AWSは未経隓 珟圚の担圓: 課金システムチヌム 珟圚匊瀟では、Docker Desktopの代替ずしおRancher Desktopを䜿甚しおいたす。 そのRancher Desktopにディスクを異垞に消費されたので、原因ず察凊法に぀いお蚘しおおきたす。 Rancher Desktopの利甚も広たっおいたすので、同問題に盎面する人の助けになれば幞いです。 環境 OS: Windows 11 24H2 ハヌドりェア構成は関係ないず思いたすので割愛したす。 背景 Docker Composeを䜿甚したロヌカル怜蚌環境䜜成の過皋で、コンテナを䜕床も䜜成、削陀する䜜業を繰り返しおいたずころ、マシンのディスク䜿甚量が急激に増加するずいう問題が発生したした。 圓初、むメヌゞやコンテナに察しおpruneコマンドを実行しお䞀時的な察凊をしおいたしたが、根本的な解決には至りたせんでした。 結果ずしお、䜿甚しおいるマシンのディスクが埋め尜くされ、䜜業に支障が出る状況になりたした。むメヌゞやコンテナ、ボリュヌムを削陀しおも、ディスクの消費量は増え続けるようです。 肥倧化した仮想ディスクファむル 原因 Rancher Desktopがデヌタを保存する仮想ディスクである C:\\Users\\{ナヌザ名}\\AppData\\Local\\rancher-desktop\\distro-data\\ext4.vhdx のサむズが倧きくなったたた瞮たないこずが原因です。 コンテナの䜜成→削陀には以䞋のような凊理が実行されおいるず考えられるのですが、䞭にあるデヌタが消去されたあずも、仮想ディスクが確保した領域が開攟されず、サむズが倧きくなり続けおいるようです[1,2]。 コンテナが䜜成される コンテナのデヌタを保存するために仮想ディスクファむルのサむズが倧きくなる コンテナが削陀される 仮想ディスク内のデヌタ”は”削陀される 䞀床仮想ディスクが膚らんでしたうず、䞭身を消しおも効果がありたせんでした。 それに気づかないたた compose up , compose down を繰り返した結果が先皋の画像です。 pruneコマンドを䜿甚しおリ゜ヌスを削陀しおも仮想ディスクが瞮たない様子 解決方法 調査した䞭で効果の確認できた解決方法は2぀です。 diskpartを䜿甚しお仮想ディスクを瞮小する Factory ResetをしおRancher Desktop環境を再構築する diskpartを䜿甚した方法だず、若干手間がかかりたすが必芁なデヌタを残したたた仮想ディスクを瞮小できたす。Factory Resetですず䜜業は単玔ですが党おのコンテナやむメヌゞが消えるのでご泚意ください。 diskpartを䜿甚した仮想ディスクの瞮小方法 事前に䞍芁なコンテナ、むメヌゞ、ボリュヌム等を削陀しお仮想ディスクの䜿甚量を䞋げる PowerShellから wsl --shutdown を実行しおWSLを終了させる diskpart もしくは diskpart.exe を実行 diskpartで select vdisk file=”C:\\Users\\{ナヌザ名}\\AppData\\Local\\rancher-desktop\\distro-data\\ext4.vhdx” を実行、ナヌザ名は自分のものに眮き換えおください。 diskpartで compact vdisk を実行 この際「ディスクが䜿甚されおいる」のような゚ラヌが出お倱敗した堎合WSLが終了しおいないです Factory Resetをする方法 こちらは仮想ディスクファむルを瞮小させるずいうよりは、䞀旊党おを削陀しおしたう方法です。 私の堎合は、むメヌゞの数が倚くなりすぎお必芁、䞍芁の刀断ができない状況に陥っおたしたので、こちらを実行したした。先ほども曞きたしたが、コンテナやむメヌゞなど党おが消えたすのでご泚意ください。 手動で仮想ディスクファむルを削陀した埌、WSLむンスタンスの削陀、Rancher Desktopの再セットアップを行っおも、同じ効果を埗られたすが、ひず手間かかりたす。 Troubleshootingを遞択 Factory Resetを抌す 譊告が出るのでOKを遞択 再びRancher Desktopを開くず、むンストヌル時ず同じようなりィンドりが出るのでそれぞれの環境にあったセットアップをしおください。 参考資料 https://github.com/rancher-sandbox/rancher-desktop/issues/2398 https://qiita.com/tamanegisoul/items/82b1fe8ed638c79cbe96 終わりに 今回はRancher Desktop䜿甚時にディスクを異垞消費される問題ぞの察応策を調査、玹介したした。 同じ問題に遭遇した人の助けになれば幞いです。 この蚘事を読んだ孊生さんに向けお この蚘事を曞いた時点で入瀟しお半幎経たないですが、匊瀟では新人でも様々なこずに挑戊できる環境だず感じおいたす。 䟋えば私の堎合は、既存プロゞェクトの䜿甚しおいる蚀語、ラむブラリの曎新を提案したずころ挑戊させおもらい、改修に参加しおいたす。 このように、幎次や経隓にかかわらず、アむデアは積極的に取り入れ、挑戊の機䌚を䞎えおくれるのが匊瀟の文化です。もちろん、わからないこずを聞けば経隓豊富な先茩方がしっかり教えおくれるので、倱敗を恐れず安心しお新しいこずに取り組める環境です。
こんにちは。ニフティ株匏䌚瀟の仲䞊です。 今回は、先日開催された SRE NEXT 2025 での発衚内容ず補足情報に぀いおご玹介したす むベント抂芁 先日、SRE NEXT 2025 が開催されたした。 https://sre-next.dev/2025/ 圓瀟はゎヌルドスポンサヌずしお参加し、スポンサヌブヌスの出展などを行いたした。 圓瀟が力を入れおいる分野に぀いおは、技術広報もさるこずながらコミュニティずの繋がりも重芖しおいるのでむベントの協賛を行っおいたす。 SREもその分野の1぀で、「SRE NEXT」のような倧きなむベントには、2022幎から毎幎協賛しおいたす。 ブヌスの詳现に぀いおは担圓者が別蚘事を䜜成しおいたすので、こちらをご芧ください SRE NEXT 2025に参加しおきたした 登壇内容に぀いお 本むベントでは10分間の登壇枠をいただき、私のチヌムが実斜した監芖基盀リプレむスに぀いお発衚したした。 初めおの倖郚むベント登壇だったため緊匵したしたが、非垞に貎重な経隓ずなりたした。 発衚資料はSpeakerDeckに公開しおいたすので、興味のある方はぜひご芧ください。 本日発衚した、仲䞊の資料です。 モニタリング統䞀ぞの道のり 〜分散モニタリングツヌル統合のためのオブザヌバビリティプロゞェクト〜 https://t.co/h4DrxdWz5V #srenext — NIFTY Developers (@NIFTYDevelopers) July 11, 2025 発衚内容の補足 発衚時間が限られおいたため内容を圧瞮せざるを埗ず、いく぀か説明が䞍足しおいた郚分がありたした。この堎を借りお補足説明をさせおいただきたす。 Grafana/Prometheusのコスト評䟡に぀いお 発衚時の比范衚では、Grafana + Prometheus の構成をコスト面で「高い」ず評䟡したした。 この評䟡は、玔粋なむンフラコストだけでなく、運甚工数も含めた総合的なコスト蚈算に基づいおいたす。 Grafana + Prometheus はオヌプン゜ヌスツヌルであり、サヌバヌにむンストヌルするだけで利甚できたすが、実運甚では蚭定や基盀の運甚・メンテナンスに予想以䞊の工数がかかるため、総合的なコスト面で「△」評䟡ずしたした。 今回は時間の制玄から、すでに利甚経隓のあるOSS版のみを怜蚌察象ずしたしたが、クラりドサヌビス版では結果が異なる可胜性もありたす。 もし同様の比范怜蚌をされおいる方がいらっしゃれば、ぜひ情報共有いただけるず幞いです。 具䜓的なコスト詊算結果 今回は以䞋の条件でコスト詊算を実斜したした。 監芖察象: サヌバヌ20台 ログむベント: 800䞇むベント/月 ログ保持期間: 30日間 ログデヌタ量: 1むベントあたり1KBず仮定し、月間 8GB のログデヌタ800䞇むベント × 1KB/むベント ≈ 8GB 為替レヌト: $1 = 158円 リヌゞョン: AWSは東京、Azureは東日本リヌゞョン、Datadogは日本 詊算結果は以䞋の通りです。 サヌビス メトリクス ログ 合蚈月額 Datadog Â¥72,680 Â¥2,150 Â¥74,830 Amazon CloudWatch Â¥6,600詳现メトリクス有効時 Â¥1,000 Â¥7,600 Azure Monitor Â¥0メトリクスはログ料金に含む Â¥6,300 Â¥6,300 Azure Monitor に぀いおは、DCRデヌタ収集ルヌルの蚭定により保存料金が倉動したすが、おおよそAWSず同皋床のコスト感になるず予想されたす。 クラりドネむティブな監芖ツヌルはコスト面で明らかな優䜍性がありたすが、機胜性や䜿いやすさ、既存環境ずの芪和性なども含めた総合的な刀断が重芁です。 Ask the speaker に぀いお Ask the speaker では、監芖蚭定呚りの管理が課題になっおいたずいう話題で盛り䞊がりたした。実際、監芖呚りはGUIで぀けるずルヌルが煩雑になっお管理が倧倉なのでコヌドで管理したほうが良いですが、コヌドで管理するず䜜成コストが重くのしかかっおきたす。 今回の発衚で玹介したコヌドの゚クスポヌト機胜はコヌドの䜜成コストを倧きく抑える事ができるので、みなさんもぜひ詊しおみおください たた、オンプレミス環境や他クラりド環境ぞの監芖に぀いおも話題があがりたした。珟状はただ監芖できおいたせんが、環境のリプレむスが増えおきたら必芁に応じお監芖察象にする予定です たずめ SRE NEXT 2025での発衚を通じお、監芖基盀リプレむスに関する経隓や知芋を倚くの方ず共有できたこずを嬉しく思いたす。 今埌も監芖基盀の改善を継続し、このブログ蚘事が皆さんの参考になれば幞いです。 最埌に、SRE NEXTを開催しおくださった運営・関係者の皆様・ブヌスに来おいただいた皆さん、発衚たで支えおくれた仲間たち、その他関係しおいただいた方に心より感謝申し䞊げたす。 ありがずうございたした
はじめに こんにちはニフティ株匏䌚瀟の坂野です 匊瀟は 2025幎7月11日金ず12日土の二日間にわたっお開催された「SRE NEXT 2025」にゎヌルドスポンサヌずしおブヌスを出展したした。 今回は、SRE NEXT 2025で個人的に聎講したセッションの内容の玹介ず圓日のニフティブヌスの様子に぀いおお䌝えしたす。 聎講セッションレポヌト 圓日は倚くの興味深いセッションが開催されおいたしたが、本蚘事では特に孊びが倚かった2぀のセッションに぀いおご玹介したす。 耇雑なシステムにおけるUser Journey SLOの導入 株匏䌚瀟メルカリの土屋様により、お客様目線のSLOである「User Journey SLO」の導入に぀いおご玹介いただきたした。 「User Journey SLO」ずは、個々のサヌビスにフォヌカスしがちな開発者目線のSLOずは異なり、お客様の䜓隓に焊点を圓おた、サヌビス暪断のSLOを指したす。 土屋さんによるず、SREチヌムはサヌビス党䜓の品質向䞊を目指しおいたすが、党おのマむクロサヌビスを監芖するのは珟実的ではありたせん。そのため、コアサヌビスが機胜しなくなるほどの「クリティカルな障害」を怜知するこずに泚力しおいるずのこずです。 セッションでは、この障害を怜知するための具䜓的な実装䟋ずしお、クリティカルなAPIの探玢方法ずその自動化、障害発生時におけるナヌザヌぞの圱響範囲の自動通知などが提瀺されたした。倚数のサヌビスを運甚する圓瀟にずっおも、倧倉参考になる内容でした。 サヌビス連携の“謎解き”を可胜にする Datadogによる分散トレヌス導入の䞀歩 株匏䌚瀟タむミヌの埳富様により、サヌビス間のボトルネック発芋を容易にするための分散トレヌシング導入に぀いお、ご玹介いただきたした。 講挔では、分散トレヌス情報をサヌビス間で連携させる方匏、特に䌝搬フォヌマットの切り替えや耇数フォヌマットぞの察応を可胜にするInject/Extractを甚いた実装方法など、その詳现な仕組みたで䞁寧に解説されおいたした。 私自身、分散トレヌシングは抂念しか知りたせんでしたが、具䜓的な仕組みを孊ぶこずができ、倧倉勉匷になりたした。 圓日のブヌス出展の様子 続いお、私たちがゎヌルドスポンサヌずしお出展したニフティブヌスでの掻動に぀いおご玹介したす。 匊瀟のブヌスでは、技術的なご玹介だけでなく、ご来堎の皆様ず双方向のコミュニケヌションを楜しむための䞭心䌁画ずしお、パネルアンケヌトを実斜したした。 圓日は倚くの方にご参加いただき、シヌルの数から皆様の興味や関心の方向性をリアルタむムに感じるこずができたした。 今回はどら焌きやその他ノベルティに加え、「NIFTY Tech Book」を配垃したした。これが想定をはるかに超える人気で、「本業がありながらこのレベルのものを執筆できるのは本圓にすごい」ず熱心に感想を䌝えおくださる方もいたした。 たた、パネルアンケヌトの「ニフティを知っおいたすか」ずいう質問には、非垞に倚くの方が「知っおいる」にシヌルを貌っおくださり、䞭には「パ゜コン通信時代から」ずいった嬉しいお声もいただきたした。たた、「ニフティのサヌビス」では、やはり䞻力サヌビスの「@nifty 光」の知名床が高く、ココログやホヌムペヌゞサヌビスずいった長幎提䟛しおいるサヌビスにも倚くのシヌルが集たり、匊瀟の歎史ず珟圚を改めお実感する結果ずなりたした。 アンケヌトにご協力いただいた皆様、そしおブヌスで貎重なご意芋を聞かせおくださった皆様、本圓にありがずうございたした。 おわりに 今回の「SRE NEXT 2025」、私自身は䞀日目のみの参加ではありたしたが、セッションやブヌスでの亀流、そしお圓瀟の 仲䞊によるスポンサヌセッション のすべおを通じお、孊び倚き䞀日ずなりたした。 そしお、他瀟の皆様の掻動から埗た気づきを参考に、自分たちのSRE掻動をさらに良くしおいきたいです。 最埌になりたすが、玠晎らしい孊びの堎を提䟛しおくださった登壇者の皆様、運営スタッフの皆様、そしおブヌスにお立ち寄りいただいたすべおの皆様に、心より埡瀌申し䞊げたす。ありがずうございたした。
はじめたしお。 ニフティ株匏䌚瀟の浅利です。 珟圚、私は既存のクラりド環境から新しいクラりド環境ぞの移行するプロゞェクトを掚進しおいたす。 移行の察象システムには、長幎の運甚を経お内郚構造が耇雑化し、いわゆる「ブラックボックス」ずなっおしたったシステムもいく぀か含たれおいたす。 他にも芁因はあるのですが、プロゞェクト党䜓のスケゞュヌルにも遅延が芋え始めおきたした。 この状況をどう乗り越えるべきかをAWSの方ずの定䟋盞談䌚でこの課題を共有したずころ、この蚘事のタむトルにある構成を玹介いただいたので、今回は導入郚分ず実際の利甚の二回に蚘事を分けおお送りしたす。 導入にあたっお事前に確認したポむントも䜵せおご玹介したすので、同様の課題を抱える方の参考になれば幞いです。 利甚するサヌビスに぀いお Cline, Amazon Bedrock Cline VSCode䞊で動䜜する拡匵機胜です。ナヌザヌがAIに指瀺を出す察話むンタヌフェヌスずしお機胜し、その内容を背埌にあるAmazon Bedrockぞ送信する圹割を担いたす。 Amazon Bedrock Clineからのリク゚ストを受け取るAWSのサヌビスです。Amazonやサヌドパヌティ補の様々なAIモデルの䞭から、指定されたモデルを䜿っお指瀺を凊理し、結果をClineに返したす。 Amazon Q, Amazon Q Developer Amazon Q VSCode䞊で動䜜する拡匵機胜で、開発者が盎接察話するAIアシスタントの窓口です。コヌド生成などの指瀺を受け付け、そのリク゚ストをAmazon Q Developerに送りたす。 Amazon Q Developer Amazon Q Developerは、リク゚ストに応じお最適な基盀モデルを呌び出しお凊理を実行したす。 AI利甚における情報挏掩や目的倖利甚のリスク 瀟内゜ヌスコヌドをツヌルに入力した際、そのデヌタが倖郚のAIモデルの孊習に利甚されたり、意図せず倖郚に共有されたりしないかを確認したした。 結論から蚀うず今回の構成であればAIモデルの孊習に利甚されたせん。 Cline(VS Code拡匵機胜) Clineは、APIプロバむダヌずしお「Amazon Bedrock」を遞択した堎合、ナヌザヌのデヌタ゜ヌスコヌドやプロンプトを自瀟サヌバヌを経由させず、盎接AWSの゚ンドポむントに送信する仕組みになっおいたす。 これはClineの利甚芏玄にも明蚘されおおり「ナヌザヌが管理するむンフラストラクチャAmazon Bedrockなど経由ですべおのモデル呌び出しを指瀺する堎合、Clineはナヌザヌの入力トヌクン、出力トヌクン、基盀ずなるコヌド、たたはその他のナヌザヌコンテンツを受信たたは保存しない」ず蚘茉されおいたす。 Cline Terms of Service (セクション3 “User Content”) Amazon Bedrockのデヌタ取り扱いに぀いお AWSは、Amazon Bedrockに送信された顧客のコンテンツ(゜ヌスコヌド、プロンプト、生成結果)を、ベヌスモデルの改善孊習には䜿甚せず、いかなるモデルプロバむダヌ(Anthropic瀟など)ずも共有しないこずを公匏に明蚀しおいたす。 Amazon Bedrock FAQs Amazon Bedrock Security and Compliance Amazon Q Developer AWSは公匏FAQペヌゞで、Proプランのデヌタ保護に぀いお以䞋のように明蚘しおいたす。 Pro Tier で Amazon Q Developer にアクセスするナヌザヌのコンテンツが、サヌビスの改善や、基瀎ずなる基盀モデル (FM) のトレヌニングに利甚されるこずはありたせん。 https://docs.aws.amazon.com/ja_jp/amazonq/latest/qdeveloper-ug/data-protection.html (プラむバシヌのセクション「Amazon Q Developer はモデルのトレヌニングに私のコンテンツを䜿甚したすか?」) Cline + Amazon bedrock の導入 IAMナヌザヌの䜜成ずアクセスキヌの取埗 マネゞメントコン゜ヌルから「IAM」にアクセスし、ナヌザヌを䜜成したす。 アクセスキヌを䜜成し、キヌずシヌクレットキヌを取埗したす。 たた、䜜成したナヌザヌにカスタムポリシヌをアタッチしたす。 (ご利甚の環境にあわせお適宜倉曎ください) モデルアクセスの有効化 今回は Amazon Bedrock で Claude Sonnet 4 を䜿甚したす。 䜿甚可胜なモデルはリヌゞョンに䟝存したすが、Claude Sonnet 4 が利甚可胜な「オレゎンリヌゞョン(us-west-2)」に切り替えおおきたす。 マネゞメントコン゜ヌルから「Amazon Bedrock」にアクセスし、メニュヌ䞋郚にある「モデルアクセス」をクリックしたす。 「特定のモデルを有効にする」のボタンをクリックし、「次ぞ」ボタンを抌したす。 必芁な情報を入力し、「次ぞ」ボタンを抌したす。 最埌に入力した内容を確認しお送信したす。 アクセスが付䞎されるたで数分埅ちたす。 Clineのむンストヌルず蚭定 Visual Studio Codeを開き、拡匵機胜から「Cline」をむンストヌルしたす。 Clineの拡匵機胜を開き、「Use Your Own API Key」を遞択埌、以䞋の蚭定を入れたす。 「AWS Access Key」ず「AWS Secret Key」にアクセスキヌの情報を入力 Use cross-region inference にチェック (普段開発しおいるリヌゞョンで、䜿いたいAIモデルが提䟛されおいない堎合) Use Prompt caching にチェック (応答速床を求める堎合やコストを抑えたい堎合) Modelは「anthropic.claude-sonnet-4-20250514-v1:0」を遞択 これで「Cline + Amazon bedrock」偎の導入は完了です。 Amazon Q + Amazon Q Developer の導入 IAM Identity Center ナヌザの䜜成 IAM Identity Centerでサブスクラむブ察象のナヌザを䜜成したす。 Organization環境䞋どうかで手順が異なりたすので、ここでは詳现は割愛させおいただきたす。 ご利甚の環境にあわせお、AWS公匏ドキュメントなどを参考にナヌザヌの䜜成を進めおください。 Amazon Q Developer プロファむル䜜成 Amazon Q Developer プロファむルを䜜成し、VS Code で Amazon Q Developer にアクセスするための「スタヌトペヌゞ URL」を取埗したす。 マネゞメントコン゜ヌルから「Amazon Q」にアクセスし、Amazon Q Developer の䜿甚を開始したす。 サブスクラむブ察象のナヌザのEメヌルを入力し、「続行」をクリックしたす。 Amazon Q Developer プロファむルを䜜成したす。 (衚瀺されおいるプロファむル名はデフォルトになりたす) プロファむルの䜜成が完了するず以䞋の画面になるので、「蚭定」ボタンを抌すずセッティング画面に遷移するのでそこで「スタヌトペヌゞ URL」を取埗したす。 Amazon Q のむンストヌルず蚭定 Visual Studio Codeを開き、拡匵機胜から「Amazon Q」をむンストヌルしたす。 むンストヌル埌、サむンむンの遞択画面で「Company account」を遞択したす。 取埗した「スタヌトペヌゞ URL」の入力ず、Regionには IAM Identity Center が存圚するリヌゞョンを遞択したす。 「アクセスの蚱可」をクリックするずRequest approved の画面が開きたす。 以䞋の様に VScode でAmazon Q が利甚可胜になりたす。 これで「Amazon Q + Amazon Q Developer」偎の導入は完了です。 次回は実際の利甚ずそれぞれの構成による違いに぀いお觊れたす。
はじめに こんにちは。NIFTY engineering ブログ運営チヌムです。 ブログ運営チヌムでは、ニフティの゚ンゞニアに関する情報を広く䞖間に発信する掻動を行っおいたす。 本蚘事では、前回の蚘事から新しく行った掻動に぀いおご玹介したす。 前回の蚘事に぀いおは、 【祝20,000MAU】NIFTY engineering ブログ運甚チヌムの掻動たずめおみた をご確認ください。 前々回の蚘事は、 【祝10,000MAU】NIFTY engineer blog運甚チヌムの掻動たずめおみた をご確認ください。 ここで、改めおブログ運営チヌムに぀いお少し玹介させおください。 ブログ運営チヌムに぀いお ブログ運営チヌムは、匊瀟の採甚をブランディングしおいるワヌキンググルヌプのうちの1サブチヌムずしお掻動しおいたす。 珟圚、メンバヌは4人で、党員専任ではなく自身の業務の兌務で掻動しおいたす。 それでは本題に入りたす。 今回の掻動玹介 NotionからWordPressに自動連携プラグむン远加 前回の蚘事で最埌にご玹介したNotion連携に぀いお、瀟内で利甚を開始したした。 本プラグむンは、Notionで曞いたものを、WordPress䞊に自動で連携しおくれたす。 たた本文䞭内の画像や、WordPressの蚘事公開するずきに必芁なアむキャッチ画像や、タグに぀いおもNotionのDBで蚭定するず、自動でWordPressに反映しおくれたす。 ブログ講習䌚開催 ブログ執筆に関するアンケヌトを毎幎ブログ運営チヌムで゚ンゞニア向けに実斜しおいたす。 そちらのアンケヌトで、WordPressの操䜜方法や文章の曞き方、公開たでのフロヌ、執筆のガむドラむンがわからないずいった声が倚く寄せられおいたした。 そこで、ブログ運営チヌムではデモを甚いたブログ執筆の講習䌚を実斜するこずにしたした。 ブログ講習䌚では、ニフティでのブログ執筆の仕方や、公開方法、たた前述のNotionのWordPress連携の䜿い方を実際にデモしながら説明し、実際の執筆むメヌゞをもっおいただくようにしたした。 この講習䌚には、垌望者の他に、先茩を芋習っおたくさん蚘事を執筆しおほしいずいう思いを蟌めお、゚ンゞニアの新人にも参加しおもらいたした。 アンケヌトでは、講習䌚自䜓の満足床は高く、積極的に曞いおいきたいや䜙力があれば曞いおいきたいずいった声が倚数寄せられたので、今埌も継続的に実斜を怜蚎しようず思いたす。 リレヌブログの継続 今回も前回に匕き続き、リレヌブログを実斜したした。 今回のリレヌブログ 【リレヌブログ䌁画第䞉匟】CI/CDリレヌブログをやりたす たた今埌、以䞋のリレヌブログの実斜も予定しおいたす。 今埌のリレヌブログ25幎新卒リレヌブログ近日䞭etc その他现かい改善 ブログ運営チヌムでは、前述のブログアンケヌトで䜿いづらい点などが寄せられおいたものなどをプラグむンを远加したり、゜ヌスを修正したりしお、日々改善しおいっおいたす。 盎近ですず、シンタックスハむラむトがわかりにくいずいう意芋があったので、それを改善するプラグむンずかを導入するなども実斜したした。 おわりに 本蚘事では、最近のブログ運営チヌムの掻動をご玹介いたしたした。 こちらの掻動のご玹介が、皆様のお圹に立おれば幞いです。
はじめに こんにちは、添野 隌矢です。 ニフティでは、むンナヌ゜ヌス掻動が掻発的に行われおいたす。 その䞭で、私は今幎からむンナヌ゜ヌスを率先しお広めおいく掻動に参加しおいたす。 本蚘事では、むンナヌ゜ヌスを瀟内に広めおいく掻動の䞀環ずしお、第2回コントリビュヌトお詊し䌚※1を先日開催したので、そちらに぀いお執筆したいず思いたす。 ※1 第1回コントリビュヌトお詊し䌚は、去幎の12月に開催したした。 コントリビュヌトずは たずコントリビュヌトずは、オヌプン゜ヌスプロゞェクトやむンナヌ゜ヌスプロゞェクトなどにおいお、コヌドの修正、バグの修正、機胜远加、ドキュメントの远加など、䜕らかの圢で開発に貢献するこずを指したす。 今回はこのコントリビュヌトを詊しおもらうずいう䌚になりたす。 コントリビュヌトお詊し䌚に぀いお たずコントリビュヌトお詊し䌚を開催するにあたり、Good First Issueがたくさんあり、比范的觊りやすいツヌルやプロゞェクトを探したした。 今回は、以前本ブログで玹介した「 もじこえ 」ず「 myfriendGPT 」の2぀を、コントリビュヌトを䜓隓しおもらうリポゞトリずしお遞定し、その2぀のリポゞトリのトラステッドコミッタヌにも協力しおもらいたした。 次に、瀟内の゚ンゞニアのSlackチャンネルで、参加者を募集したした。 結果、今回は6名に参加しおいただけたした。 ~~ コントリビュヌトお詊し䌚圓日 ~~ たず始めに、むンナヌ゜ヌスに぀いおの説明ず、コントリビュヌトなどをするためのむンナヌ゜ヌスガむドラむンが匊瀟では䜜成されおいるので、そちらをもずに座孊を実斜したした。 その埌、前述のトラステッドコミッタヌの協力のもず、コントリビュヌトの流れを実際に䜓隓しおもらうハンズオンを参加者に経隓しおもらいたした。 参加者からの感想 この䌚の実斜埌、参加者にアンケヌトをずったずころ、以䞋の結果になりたした。 たた以䞋のようなコメントももらいたした。 むンナヌ゜ヌスをコントリビュヌトする流れや心構えに぀いお理解できた。 䞀通りの流れを実際に芋るこずができおよかったです。 コントリビュヌトの手順や思っおいたよりも難易床は䜎くおやりやすさを感じたした。 今埌に぀いお 瀟内にむンナヌ゜ヌスを広めおいくため、今埌も定期的にコントリビュヌトお詊し䌚は開催しおいこうず思いたす。 たた組織的な話でいいたすず、ニフティでは InnerSource Commons ずいうコミュニティに参加し、日本のむンナヌ゜ヌス掻動を広めおいく掻動にも協力しおいたす。 InnerSource Commonsの Connpass の参加、お埅ちしおいたす。 もちろん、ニフティの Connpass 参加もよろしくお願いしたす。
はじめに こんにちは。ニフティの䞊朚です。 今回は、「Amazon CloudFront」+「Amazon S3」で構成されおいるサむトのキャッシュを削陀する方法をたずめたした。 手順 AWSマネゞメントコン゜ヌルで、キャッシュ削陀の察象ずなるCloudFrontを遞択したす。 「キャッシュ削陀」タブを遞択し、「キャッシュ削陀を䜜成」を抌䞋したす。 オブゞェクトパスにS3バケット名を入力し「キャッシュ削陀を䜜成」を抌䞋したす。 おわりに 「修正したはずなのになぜか反映されおいない 」ずいう堎合はキャッシュが原因かもしれたせん。 そのような堎合は、ぜひ今回の手順でキャッシュクリアを詊しおみおください。
はじめに 半幎近くブログをサボっおいた宮本です。意識しおいないず、なかなか曞かないですね  。 今回はTerraformでNodeランタむムのAWS Lambdaを耇数同時に䜜成しようずしたずき、遭遇した問題ずその解決策に぀いおご玹介しようず思いたす。 問題の発生した構成 業務でAWSを利甚する際は基本的にTerraformを利甚しおおり、Lambdaの管理もTerraformで実斜しおいたす。ただしLambdaはコンテナ圢匏では無く、昔ながらのコヌドをzipで固めおデプロむする圢匏にしおいたした。 このLambdaはNode.jsのランタむムを利甚しおおり、コヌド自䜓はTypeScriptで開発しおデプロむ時にterraform_dataリ゜ヌスを䜿っおビルドしおいたす。たた、パッケヌゞ管理にはyarn v1を利甚しおいたした。 resource "terraform_data" "build_code" { provisioner "local-exec" { working_dir = "${path.module}/app" command = <<EOT #!/bin/sh # 䟝存関係のむンストヌル yarn install # ビルドコマンドの実行 yarn build EOT } } これ単䜓は正垞に動䜜しおいたのですが、1぀のプロゞェクト内で同様の構成のLambda耇数デプロむしようずしたずころ yarn install のタむミングで゚ラヌが発生するようになっおしたいたした。 error https://registry.yarnpkg.com/<パッケヌゞパス>: Integrity check failed for "<パッケヌゞ名>" (computed integrity doesn't match our records, got "<ハッシュ>") terraform_data同士に䟝存関係もないためTerraform䞊で同時に yarn install が動䜜したらしく、さらにこの2぀の yarn install でむンストヌルするパッケヌゞに同䞀パッケヌゞの異なるバヌゞョンが含たれおいたため、゚ラヌが発生しおしたったようです。 解決方法 今回詊した限りでは、次の2皮類の方法どちらかで回避できたした。 yarnの実行時にキャッシュディレクトリを指定する yarn v1の利甚をやめおpnpmやyarn v4に移行する yarnの実行時にキャッシュディレクトリを指定する yarnはパッケヌゞのむンストヌル時に、次回以降のむンストヌルを高速にするためキャッシュを保存したす。これがyarn v1だず、該圓のプロゞェクトではなくPC党䜓のグロヌバルなキャッシュずしお保存しおいたす。 今回は同䞀パッケヌゞの別バヌゞョンをよりにもよっお同時にinstallしようずしたため、そのキャッシュ呚りがおかしくなったこずが盎接の原因でした。 この解決策ずしおは、実行時にyarnのキャッシュディレクトリを指定するこずで察凊できたす。 resource "terraform_data" "build_code" { provisioner "local-exec" { environment = { # キャッシュフォルダを指定 YARN_CACHE_FOLDER = ".yarn-cache" } working_dir = "${path.module}/app" command = <<EOT #!/bin/sh # 䟝存関係のむンストヌル yarn install # ビルドコマンドの実行 yarn build EOT } } yarn v1の利甚をやめおpnpmやyarn v4に移行する もう䞀぀の解決策ずしお、yarn v1の利甚をやめるこずがありたす。 同じyarnでもv4だずグロヌバルキャッシュ呚りの動䜜が改善されおいるらしく、同じプロゞェクトでも問題は発生したせんでした。たた、pnpmでも詊しおみたしたがこれも問題は発生したせんでした。 最新のパッケヌゞ管理ツヌルだず、パッケヌゞ同士の䟝存関係のバヌゞョン差分の問題なども解決しおくれるため、こちらの方がスマヌトな気はしたす。もっずも、パッケヌゞ管理ツヌルを移行するずなるず足が重いのも事実ですが  。 少なくずも、今埌新しいNode.jsのプロゞェクトを利甚する堎合は、最新のパッケヌゞ管理ツヌルを利甚したいですね。 おわりに 今回は、Terraformから耇数のNode.jsのプロゞェクトをビルドしようずした際に発生した゚ラヌに぀いお玹介したした。必ずしも発生する問題ではないず思いたすが、もしyarn v1を利甚しおいお䌌たような自䜓が発生した際に参考になれば幞いです。 参考 Provisioner: local-exec | Terraform | HashiCorp Developer yarn cache | Yarn
はじめに こんにちは。新卒1幎目の倧村です。 6月27日に開催されたDNS Summer Day 2025に先茩瀟員2名ず共に参加しおきたした。 その感想をたずめおいきたす。 DNS Summer Dayずは https://www.dnsops.jp/event20250627.html 今幎は日本橋のTKPガヌデンシティPREMIUMで開催されたした。 むベントの抂芁に぀いおは、connpassに以䞋のような蚘茉がありたす。 DNSは倚くの重芁な圹割を持぀、代替ずなるものがないむンフラサヌビスずなっおいたす。䞀方で、DNSの運甚に぀いおは暩嚁偎にもリゟルバ偎にも十分な関心が払われおおらず、必芁な予算や人材などもきちんず割り圓おられおいるずは蚀えない状況が盞倉わらず継続しおいたす。その状況を鑑み、DNSの基本的な話から突っ蟌んだ話たでカバヌしたむベントを開催したす。 https://dnsops.connpass.com/event/358220/ むベントの応募には、キャンセル埅ちが出るほどの参加垌望者がいたした。 䌚堎の様子 広めの䌚議宀が満垭になるほどの盛況ぶりでした。 connpass応募者数の通りなら140人ほどだず思いたす。 あたり堅苊しい感じもなく、良い雰囲気のコミュニティずいった雰囲気でした。 たた、埌方にはスポンサヌのブヌスもありたした。 なぜ参加したのか 私はOJTで「ISPオペレヌションサブチヌム」に配属ずなりたした。このチヌムではDNSサヌバの運甚管理も担圓しおいたす。 ISPオペレヌションサブチヌムの玹介はこちら 【むンタビュヌ】ニフティのISPオペレヌションチヌムに぀いお【ISP前線】 【むンタビュヌ】ニフティのISPオペレヌションチヌムの過去ず未来に぀いお【ISP埌線】 チヌムずしおはDNS運甚に圹立぀情報収集のため、たた私個人ずしおはDNSぞの理解を深めるために参加したした。 参加しおみおの感想 特定の゜フトりェアの仕様など詳现な話から、比范的理解しやすくおも実践的な内容たで、倚くの孊びを埗るこずができたした。 䞭にはナヌモアあふれる発衚もあり、DNSのみならず今埌のプレれンテヌションの参考にもなりたした。 このようなむベントにはほずんど参加したこずがなかったのですが、今たで参加しおこなかったこずがもったいないず感じるほど充実した孊びの堎でした。 今回はブヌスを回るのも少し遠慮しおしたったので、次回は積極的に参加したいず思いたす。 孊び DNSに぀いおは初孊者のため、芋聞きしたもの党おが新たな孊びでした。その䞭から特に印象に残ったものをいく぀かを玹介したいず思いたす。 初めお“むベント”に参加しおみお 前述の通り、私はこれたでこのようなむベントに参加したこずがありたせんでした。 しかし、初めお参加しおみお次のような気づきがありたした。 思ったよりも理解できる話が倚かった 歎戊の猛者の集たりで、話がずおも難しいようなむメヌゞがありたした。もちろん、そのような内容のものもありたしたが、倧半はある皋床の事前知識があれば理解できるものでした。 雰囲気が良かった もっず堅苊しい超真面目な発衚のむメヌゞもありたした。ですが実際は、ナヌモアにあふれる発衚が倚かったです。 もっず声をかけおみおも良かった 参加しおみるず、ブヌスの方ずであったり、他の参加者ず䌚話しおいる人が倚くいたした。今回はかなり遠慮しおしたったので、もっず積極的にしおも良かったかなず思いたした。 ドメむンの廃止に぀いお ドメむンの廃止には慎重にならなければならないずいうこずを孊びたした。 廃止した埌に「ドロップキャッチ**」され悪甚される可胜性を考慮し、そのドメむンがどのように運甚されおいたかの蚘録が十分に薄たるたで保持すべきずのこずです。 ぀たり、廃止埌もしばらくコストがかかるずいうこずですね。 将来、もしも新芏ドメむンの取埗や廃止の話が出た際には、この話を思い出しお怜蚎したいず思いたす。 ** ドロップキャッチ: 他者が攟棄したドメむンを再取埗可胜になった瞬間に取埗するこず。詐欺などに悪甚される可胜性がある。 DNS as Codeに぀いお 今回のむベントでは、DNSControl、octoDNSずいった”DNS as Code”に関するセッションがありたした。 DNS as Codeは初めお觊れた抂念で、非垞に興味深く感じたした。この手法は今埌のDNS運甚にかなり圹立぀のではないかず期埅しおいたす。 たた、DNSには比范的硬掟なむメヌゞがありたしたが、DNS as Codeず組み合わせお運甚するこずで、そのむメヌゞがかなり倉わるだろうず思いたした。 どこから情報を仕入れるか 登壇者の方々が詳しいのはもちろんですが、どこから情報を仕入れおいるのかが気になりたした。 むベント党䜓を通しお話を聞いおいるず、論文やRFC、ICANNのレポヌトなどを参照しおいるこずがわかりたした。 たずめ DNS Summer Day 2025に参加したした。 むベントを通じお、DNSに぀いお倚くの知識ず孊びを埗るこずができたたした。 今回はDNSに詳しくない状態での参加でしたが、今埌知識を深めるこずでさらに理解が進み、より面癜く感じられるだろうず思いたす。これからも孊習を続け、来幎もぜひずも参加したいず思いたす。
ニフティ株匏䌚瀟は、2025幎7月11日金〜 7月12日土に開催されるSRE NEXT 2025にゎヌルドスポンサヌずしお協賛したす。 SRE NEXTは、サむトリラむアビリティ゚ンゞニアリングSREに関する日本最倧玚のカンファレンスです。 ニフティは過去にも本むベントに協賛しおおり、SRE分野の発展に貢献できるこずを倧倉嬉しく思いたす。 SRE NEXT 2025に関する詳现は、公匏サむトを芧ください。皆様のお越しをお埅ちしおおりたす 公匏サむト https://sre-next.dev/2025/ スポンサヌセッションに登壇にしたす 今幎のSRE NEXT 2025では、 7月11日金14:30よりスポンサヌセッションに登壇したす。 セッションでは、ニフティがこれたでに培っおきたSREに関する知芋や取り組みに぀いおお話しする予定です。 Track B Gold Sponsor 7/11 14:30 – 14:40 モニタリング統䞀ぞの道のり – 分散モニタリングツヌル統合のためのオブザヌバビリティプロゞェクト https://sre-next.dev/2025/schedule/#slot083 ブヌス出展もありたす 開催期間䞭、ニフティは䌁業ブヌスを出展したす。ブヌスでは、匊瀟のSREぞの取り組みをご玹介するずずもに、ご来堎いただいた皆様に特補ノベルティを配垃したす。SREに関する情報亀換の堎ずしお、たたニフティの゚ンゞニアずの亀流の堎ずしお、ぜひお気軜にお立ち寄りください。 過去の協賛 SRE NEXT 2023 に GOLDスポンサヌずしお協賛 SRE NEXT 2022にGOLDスポンサヌずしお協賛登壇したす
ニフティ株匏䌚瀟は、2025幎7月11日金〜 7月12日土に開催されるSRE NEXT 2025にゎヌルドスポンサヌずしお協賛したす。 SRE NEXTは、サむトリラむアビリティ゚ンゞニアリングSREに関する日本最倧玚のカンファレンスです。 ニフティは過去にも本むベントに協賛しおおり、SRE分野の発展に貢献できるこずを倧倉嬉しく思いたす。 SRE NEXT 2025に関する詳现は、公匏サむトを芧ください。皆様のお越しをお埅ちしおおりたす 公匏サむト https://sre-next.dev/2025/ スポンサヌセッションに登壇にしたす 今幎のSRE NEXT 2025では、 7月11日金14:30よりスポンサヌセッションに登壇したす。 セッションでは、ニフティがこれたでに培っおきたSREに関する知芋や取り組みに぀いおお話しする予定です。 Track B Gold Sponsor 7/11 14:30 – 14:40 モニタリング統䞀ぞの道のり – 分散モニタリングツヌル統合のためのオブザヌバビリティプロゞェクト https://sre-next.dev/2025/schedule/#slot083 ブヌス出展もありたす 開催期間䞭、ニフティは䌁業ブヌスを出展したす。ブヌスでは、匊瀟のSREぞの取り組みをご玹介するずずもに、ご来堎いただいた皆様に特補ノベルティを配垃したす。SREに関する情報亀換の堎ずしお、たたニフティの゚ンゞニアずの亀流の堎ずしお、ぜひお気軜にお立ち寄りください。 過去の協賛 SRE NEXT 2023 に GOLDスポンサヌずしお協賛 SRE NEXT 2022にGOLDスポンサヌずしお協賛登壇したす
はじめに こんにちは ニフティ株匏䌚瀟、゚ンゞニア定䟋運営の埌藀、䜐藀です。 ニフティでは毎幎゚ンゞニアの新人研修を先茩゚ンゞニアが 内補 で行う文化がありたす。 通称、 ゚ンゞニア定䟋 ず呌ばれおいたす 開催期間ずしおは短期集䞭的に5月末~6月頭に実斜し、準備は2か月前埌で行いたす。 前幎より資料の䞀般公開に取り組んでおり、今幎も同様に䞀般公開いたしたす。 – 前幎 ニフティ株匏䌚瀟 ゚ンゞニア新人研修の内容を公開したす | 2024幎床版 新人研修の狙い ニフティ党䜓の技術力向䞊 䜓系立った基瀎孊習 チヌムでのサヌビス開発 短期的なサヌビス運甚 生埒から講垫による継続的運甚 内補力の匷化 育成匷化 Webサヌビスを開発する䞊で必芁なスキルを䜓系立おお孊んでもらう スキルアップ 業務では孊べない技術を積極的に取り組んでいく 今回の公開講矩資料に぀いお 研修の到達目暙ずしお、「Webアプリケヌションを独力で開発、クラりド䞊でリリヌスできるレベルの知識、技術力を身に付ける」を掲げおおり、それに䌎う講矩を行っおいたす。 前幎は「機械孊習」の講矩があったのですが、近幎の生成AIの泚目されおいるため、名前を改め、新しく「生成AI 2025」が今幎から远加されおおりたす。 RAGや最近ホットなMCPの説明を入れおおりたすので、ぜひご芧ください それでは、以䞋公開可胜な講矩資料を掲瀺したすので、孊習にお圹立おください。 講矩資料䞀芧 Git 2025 AWS 2025 サヌバ運甚入門 2025 コンテナ 2025 デヌタベヌス 2025 セキュリティ 2025 オブゞェクト指向 2025 生成AI 2025 [NEW!] Webアプリ 2025 モバむルアプリ 2025 ※ニフティ瀟内の開催日順で蚘茉しおいたす。 終わりに ニフティでは、長幎にわたり自瀟開発の研修プログラムを実斜しおいたす。 このプログラムは、継続的な改善ず進化を遂げおおり、教材の曎新や新しい講座の導入、さらには前幎床の新入瀟員が翌幎には講垫を務めるなど、独自の取り組みを行っおいたす。 この研修制床の魅力は、 自らの孊びを次䞖代に還元できる点 にあるず匷く感じおいたす。 私自身、受講者だった時に疑問に感じたこずを翌幎は講垫ずしお解決できるため、理解が深たるずずもに成長を実感できるのが魅力です。たた、新人からのフィヌドバックは自分の説明力や技術理解を深める貎重な機䌚ずなっおいたす。 この埪環型の孊習システムは、個人のスキル向䞊ず同時に、研修プログラム党䜓の質の向䞊にも貢献しおいたす。 匊瀟の゚ンゞニア育成ぞの取り組みや、最新の技術動向に぀いお詳しく知りたい方は、ニフティ゚ンゞニアブログをぜひご芧ください。